Account with [Full Access] rights and no rights to edit the file

[Torsten]

Yesterday, a server-hosted file (1 out of 6) did not allow editing the file (long with admin account [Full Access]. Only restarting the server several times fixed it.
Today, a copy the same file exposes identical behaviour while hosted on a second server.
Servers: macOS 12.2.1 and macOS 12.4, both FMS 19.4.2.204
Client: macOS 12.4, FMP 19.4.2.204
Run integrity check on file. No errors found. Sever logs show nothing.
FMS has read and write access to file on server.

Did anyone observe this behaviour, too?

[Malcolm]

I have seen a similar message is several cases: locked media, failing drive, wrong permissions at OS level.

That is likely to be a signal that there is a problem at the level of the operating system. Check the file permissions on disk. Also, check the disk it is on, is it on a non-writable media? It may be that the disk is failing. Run hardware tests on the disk.

[jkoester]

Was the file uploaded manually or via client?

[Torsten]

Both servers are less than 1 year old M1 MacMini. Checked disks, all ok.

[Torsten]

Always manual. Client most times fails with larger files. Attribution of file permission for FMS also manual after upload, before opening the file in server.

[mike275]

You are running pretty old server and client in new and unsupported hardware/software.
maybe there is a problem in that also

[Torsten]

Sorry, these where typos. It is v 19.2.4 for both servers and client. I corrected the OP.

[Markus]

I've seen that when there are problems with access rights, maybe because of the manual upload - and when there are some problems with a file, maybe already open (??).

If You copy that file and test it local on the client machine: No problems at all? If tested local on the server machine (be carefull...): No problems?

Since there are 2 separate servers involved, I don't think that there is a hardware problem or a problem with fms - but with the files... I do no love the 'manual' method, but some system won't let You upload via clent...

Disks.. All on the startup-volume?

[Torsten]

The server is stopped and restarted each time a new file is copied into the database folder and access rights are set.

Database folder is in the library’s FMS folder. On startup volume.

I did not have time testing local access.

Agree, with two new server machines it is unlikely that a ssd failure is involved.

[Markus]

restarting fms and the server machine... just to make sure..

[Torsten]

Did so

[Markus]

something in the log's? (fm log's and system log's)

I'm afraid that problems with access rights often indicate a problem with a file - but can also be 'infra-structured'

[Torsten]

No log entries corresponding to any problem. The UI file has a script that verifies if all files of the solution can be write-accessed by the server. If not, the solution terminates with an error message. This error message is not produced and the solution starts normally, despite the issue.

[Malcolm]

Curiosity question: does the script check the owner/group privileges and the modification privileges?

General question: are all user accounts affected, or only the admin account?

[Torsten]

The script runs with the user’s privileges.
All other accounts do not have edging privs for layouts and scripts.

[jkoester]

Are the file permissions correct?

[Torsten]

The fmserver account has rw rights, the fmsadmin account does not exist on the system.

[jkoester]

please click "alt & +"

[FileKraft]

did you run any maintenance tools on the server?
run a backup and swap files with backup - if it writes backups ..

[pcsasd]

There are several persistent posts at FMI community about the failure to use Upload To Host on Macs, resulting in a few patches ( see post ) which in my case did not help on several mac mini servers.

Annoying as this is an essential step to make sure the file permissions are set correctly which is not the case when you do a manual copy paste to the data folder of FMS. Still, for some users this solved the issue so it may be wortwhile to check the patches in the link above.