After running an overnight deployment the Otto Interface shows the deployment as successful when the file has been opened as read-only. It took the client a little while to realise that the file was not modifiable resulting in some significant confusion.
Closing the file on the target server, resetting the file permissions and re-opening the file fixed the issue. It’s not a great look for us with our client.
There is no issue logged by Otto.
Source server is Ubuntu, running FMS 21.0.1.51, OttoFMS Version: 4.7.0.
Target server is MacOS, running FMS 21.0.2.202, OttoFMS Version: 4.7.0.
Hi Gabe,
Well that is pretty weird. I can understand why your customer might be worried. OttoFMS runs as the same user and group as FileMaker Server, so I am not sure how that could even happen. But I’d sure like to know if it is reproducible.
Otto doesn’t check the log to see if the file were opened as read only since that hasn’t even seemed possible before. We could do that.
If you like to send us the combined logs we can take a look to see if anything looks like a problem.
Thanks
Todd
It seemed to behave the same as if you open a file that does not have the owner ‘fmserver’, the file will open and the filemaker admin console does not complain. But no modifications can happen to the file. You can browse records, but not create new records, delete or update them.
I didn’t think to check the permission on the file, before resetting the permission. So I can’t be 100% sure if just closing the file and reopening it might have solved the issue.
I’ve PM’d you the logs.
I got the logs. I don’t see anything unusual there.
As I said earlier OttoFMS runs as the same user and with same group as FileMaker server. We do this specifically to make sure that all files that we touch, move, create, fetch etc, have the correct permissions.
Did you set up OttoFMS to run with a different user than the default?
Thanks
Todd
Hi Todd, I use your install script to install Otto:
sudo curl -sSL "https://appupdates.proofgeist.com/ottofms/install-scripts/install-linux.sh" | bash
I haven’t made any other change to the installation of Otto.
Had this same issue happen again on the same clients server. Following a successful deployment the file was opened in a state where FileMaker Server could read but not write to the file. Closing the file, resetting the file permissions and reopening the file caused it to work.
Server is running OttoFMS 4.9, FMS 21.1.1.40 and Mac OS 14.17.1.
A deployment of the same file, on the same server two weeks ago completed successfully.
Hi Gabe,
The logs are not showing anything unusual. Everything looks fine.
Does this happen every time or is it random?
Do either of the FileMaker Servers involved run FileMaker Server with a custom user and group. OttoFMS requires that FileMaker server run under the default fmserver:fmsadmin permisions.
Todd
Thanks for looking into it Todd.
It seems to be random. Sometimes does it, sometimes not. Which is strange.
Both servers have been installed with the default user and groups. User: fmserver, group: fmsadmin. I’ve only ever seen this issue on this Mac server, I’ve never seen it on Linux.
Any chance there is other backup software or antivirus running on these machines that maybe scanning or otherwise touching these files?
Todd
No antivirus.
An app called Sync Folder Pro runs periodically to copy files from /Library/FileMaker Server/Data/Backups/ to a local backup drive. It shouldn’t touch /Library/FileMaker Server/Data/Databases/
Do you think it’s possible that might be the cause?
It could be. OttoFMS uses the Library/FileMaker Server/Data/Backups/ directory for all it’s work. If that program is messing with the permissions on files in that folder then yes it could be the issue.
If you can tune it down to not include the OttoFMS folder that is in Library/FileMaker Server/Data/Backups/. then that might help
Todd
