github-starred/actual
2
0
Fork 0
mirror of https://github.com/actualbudget/actual.git synced 2026-05-06 07:01:45 -05:00
Code Issues 1.5k Packages Projects Releases 54 Wiki Activity

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

New Issue
Closed
opened 2026-02-28 19:24:41 -06:00 by GiteaMirror · 5 comments
GiteaMirror commented 2026-02-28 19:24:41 -06:00
Owner
Copy Link

Originally created by @EricJSchofield on GitHub (Feb 2, 2024).

Verified issue does not already exist?

  • 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
  • I will be attaching my server logs to this issue
  • I will be attaching my client-side (browser) logs to this issue
  • 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

Originally created by @EricJSchofield on GitHub (Feb 2, 2024). ### 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
GiteaMirror added the bug label 2026-02-28 19:24:41 -06:00
GiteaMirror commented 2026-02-28 19:24:41 -06:00
Author
Owner
Copy Link

@EricJSchofield commented on GitHub (Feb 2, 2024):

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.

@EricJSchofield commented on GitHub (Feb 2, 2024): 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? ```bash 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.
GiteaMirror commented 2026-02-28 19:24:42 -06:00
Author
Owner
Copy Link

@EricJSchofield commented on GitHub (Feb 2, 2024):

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?

@EricJSchofield commented on GitHub (Feb 2, 2024): Yeah, looks like it was a permissions error. ```bash 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?
GiteaMirror commented 2026-02-28 19:24:42 -06:00
Author
Owner
Copy Link

@purepani commented on GitHub (Feb 5, 2024):

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.

@purepani commented on GitHub (Feb 5, 2024): 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.
GiteaMirror commented 2026-02-28 19:24:42 -06:00
Author
Owner
Copy Link

@twk3 commented on GitHub (Feb 5, 2024):

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.

@twk3 commented on GitHub (Feb 5, 2024): > 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.
GiteaMirror commented 2026-02-28 19:24:43 -06:00
Author
Owner
Copy Link

@youngcw commented on GitHub (Feb 26, 2024):

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.

@youngcw commented on GitHub (Feb 26, 2024): 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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
AI generated
API
bank sync
budgeting
bug
can’t replicate
dependencies
docker
documentation
electron
experimental feature
feature
feedback
goal templates
good first issue
help wanted
importers
maintenance
needs info
needs testing
needs triage
needs votes
openid
payees
pull-request
Mirrored from GitHub Pull Request
 regression
reports
responsive
rules
schedules
server
✨ merged
split transactions
tech debt
theme
transaction import
transaction reconciliation
transactions
translations
upstream
user interface
✅ approved
wontfix
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/actual#908
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?