Migrate fail on only one of several similar servers

OttoFMS
1

Environment:
Ubuntu 22 + Docker (fmCloud.fm)
fms 21.1.1.40
OttoFMS 4.8.0

We have several servers hosting a vertical solution. We regularly use OttoFMS to upgrade a customer’s solution and this is mostly working great.

However, one server is now failing every migration we attempt with this message:

Unknown deployment error: Error: EACCES: permission denied, unlink ‘/opt/FileMaker/FileMaker Server/Data/Backups/OttoFMS/deployment-backups/deploy-17/sub-deploy-36/1267t1c3.fmp12’

We are not aware of any config difference between working and non-working servers…
Would an update to 4.8.1 be enough to fix this, or is there some other fix we should try?

2

Hello

While upgrading to OttoFMS 4.8.1 wouldn’t hurt (you can find the update instructions at Updating | OttoFMS), I don’t believe this will resolve your current permission issue.

The problem appears to be that the file permissions have changed on this specific file:

Copy

/opt/FileMaker/FileMaker Server/Data/Backups/OttoFMS/deployment-backups/deploy-17/sub-deploy-36/1267t1c3.fmp12

It likely no longer matches the expected fmsadmin/fmsuser privileges it was created with.

Here’s what I suggest:

  1. SSH into your server
  2. Delete the problematic file mentioned above
  3. You may also want to remove the entire deploy-17 folder for a clean slate

Please let me know if taking these steps resolves the issue for you. I’m here to help if you need any additional assistance!

Todd

3

I chose instead to fix the permissions with

chmod -R 775 “/opt/FileMaker/FileMaker Server/Data/Backups/OttoFMS/deployment-backups/”
chown -R fmserver:fmsadmin “/opt/FileMaker/FileMaker Server/Data/Backups/OttoFMS/deployment-backups/”

I will get back to you on monday as we’re in production now and can’t disturb our customers…
PS. Does Otto auto-clean the deployment-backups folder over time?

4

OttoFMS will clean up the deployment backups based on the number you have set to keep in the OttoFMS settings:
CleanShot 2025-01-10 at 09.43.52

When a new deployment backup gets created, it will delete the oldest backup to keep the number at this value.

-Kyle

5

As expected, migrations are again working as expected. Thanks for you help:)

1 Like