[Bug]: Regression in 24.2.0 - EACCES: permission denied, open '/data/.migrate'

[ALurker]

Verified issue does not already exist?

• [X] I have searched and found no existing issue

Is this related to GoCardless, Simplefin or another bank-sync provider?

• [ ] I have checked my server logs and could not see any errors there
• [X] I will be attaching my server logs to this issue
• [ ] I will be attaching my client-side (browser) logs to this issue
• [X] I understand that this issue will be automatically closed if insufficient information is provided

What happened?

Actual-Server Container Fails to start with read-only filesystems. This is a regression to the same behaviour that was resolved in issue https://github.com/actualbudget/actual/issues/2011. Downgrading back to version 24.1.0 allows my container to start again.

Running in k3s on a TrueNAS Scale System

Logs:

root@nas01[~]# k3s kubectl -n ix-actual-server logs pods/actual-server-custom-app-d56c4d794-7kc6x
Checking if there are any migrations to run for direction "up"...
file:///app/src/migrations.js:24
            throw err;
            ^

[Error: EACCES: permission denied, open '/data/.migrate'] {
  errno: -13,
  code: 'EACCES',
  syscall: 'open',
  path: '/data/.migrate'
}

Node.js v18.19.0

What error did you receive?

file:///app/src/migrations.js:24
            throw err;
            ^

[Error: EACCES: permission denied, open '/data/.migrate'] {
  errno: -13,
  code: 'EACCES',
  syscall: 'open',
  path: '/data/.migrate'
}

Where are you hosting Actual?

NAS

What browsers are you seeing the problem on?

Firefox

Operating System

Linux

[ALurker]

Looking a bit further, something that is new is that the .migrate file is being created in the data dir, but it doesn't seem to be being created with the correct permissions?

e@nas01:/mnt/pool01/containers/actual-server$ ls -lA
total 43
-rw-r--r-- 1 root apps 373 Dec  8 11:13 .migrate
drwxr-xr-x 2 apps apps   3 Nov  5 10:21 server-files
drwxr-xr-x 2 apps apps   4 Feb  2 15:10 user-files

Note that the .migrate is owned by root instead of apps like the rest of the files. This container is being run under the apps UID, so that would explain the access denied issue.

Not sure how it's creating the .migrate file as root however.

[ALurker]

Yeah, looks like it was a permissions error.

e@nas01:/mnt/pool01/containers/actual-server$ sudo chown apps:apps .migrate

The above command to change owner of the .migrate file back to apps allowed the server to start again on version 24.2.0

Given that I've found a way to get running again, would you prefer for the issue to be closed? Or would you want try to dive into why the ownership of .migrate wasn't of the appropriate user that the container runs under?

[purepani]

I'm finding that when upgrading from a much older version to 24.2.0, the app tries to use the migration folder "/migrate" in root instead of in the data directory I have set for the app.

[twk3]

Not sure how it's creating the .migrate file as root however.

@ALurker It looks like that .migrate file was created back on Dec 8th according to your output. The previous image probably works because it's only reading that file, and not writing to it. Vs now that you've upgraded and have new migrations to write to it.

So I'm betting this was still a leftover permission issue from last month.

[youngcw]

What you probably should do if you are still having the issue is to export all your files, the start out clean on the server to get the server side of things cleaned up, then import your files. The .migrate file lives in server-files now instead of directly in the /data folder. If you want you can try deleting the old .migrate and see what happens, but its probably safer to just start a new server and let it create the .migrate properly.