Error "Couldn't set permissions to 777: Operation not permitted" on game start and update

[Quax]

Im running Factorio 1.17.36 in Ubuntu 20.04. Out of the sudden, I receive an error message when starting the game:

Code: Select all

"Error while running reload_script: filesystem error: copy_file "<my_game-dir>/factorio/data/base/scenarios/freeplay/image.png" to ".../factorio/temp/currently-playing-background/image.png" failed. Operation not permitted.

In addition, I find the following error messages in my logfile:

Code: Select all

6.405 Warning WriteFileGuard.cpp:86: Couldn't set /home/peter/NAS_Dateien/$Peter/Games/Factorio/factorio/mods/mod-settings.tmp.dat permissions to 777: Operation not permitted
   6.405 Warning WriteFileGuard.cpp:96: Couldn't chown /home/peter/NAS_Dateien/$Peter/Games/Factorio/factorio/mods/mod-settings.tmp.dat: Operation not permitted

Code: Select all

87.770 Warning WriteFileGuard.cpp:86: Couldn't set /home/peter/NAS_Dateien/$Peter/Games/Factorio/factorio/achievements-modded.tmp.dat permissions to 777: Operation not permitted
  87.770 Warning WriteFileGuard.cpp:96: Couldn't chown /home/peter/NAS_Dateien/$Peter/Games/Factorio/factorio/achievements-modded.tmp.dat: Operation not permitted
  87.802 Warning WriteFileGuard.cpp:86: Couldn't set /home/peter/NAS_Dateien/$Peter/Games/Factorio/factorio/player-data.tmp.json permissions to 777: Operation not permitted
  87.802 Warning WriteFileGuard.cpp:96: Couldn't chown /home/peter/NAS_Dateien/$Peter/Games/Factorio/factorio/player-data.tmp.json: Operation not permitted

I haven't been changing anything on my game directory, which is located on a Synology Disc Station.

I can actually play the game, but I'm not sure whether this may cause problems in future. One problem I encountered already is that the game was unable to update from 1.1.36 to 1.1.37, reporting the same "setting to 777 not permitted" error message.

Any help is appreciated.

Thaks

[SoShootMe]

Looking at the errors generally, these seem to suggest a change related to the user Factorio is running as:

• "Couldn't set ... permissions to 777: Operation not permitted" suggests the target is not owned by the effective uid.
• "Couldn't chown ...: Operation not permitted" suggests the effective uid is not root. However, that should be expected and I'm not sure why the game would attempt to chown anything anyway.
• "copy_file ... failed. Operation not permitted" is less clear. I'd guess the error is coming from a call like chmod or chown as above, because permission-related issues that may arise when opening/creating files or directories (as must happen to copy a file) do not result in this error (they result in "Permission denied" instead).

Since you mention the files are on a NAS, there are more ways for issues to arise. I would recommend having the files stored locally if you can; it may sidestep problems and is likely to be better performance too.

If you must have files stored remotely, see if you can get any diagnostic logs from the NAS. If you're not already, use NFS to mount. Ensure the exported directory (on the NAS) is on a filesystem that supports Unix semantics. If you are using NFSv4, check for idmap issues (eg domain setting).

[Quax]

I'll follow these hints, however I don't understand where the problem comes from, as I didn't change anything on my settings regarding NAS, ... and Factorio has been running fine for several years now.

[orzelek]

I'll follow these hints, however I don't understand where the problem comes from, as I didn't change anything on my settings regarding NAS, ... and Factorio has been running fine for several years now.

Any windows/other software updates that might be related recently?

[Quax]

Well, the regular Ubuntu update, but I doubt this changes the permissions for my NAS share ... question is how should I set the permissions on this share to allow for Factorio to set the neccessary permissions runtime?

[posila]

However, that should be expected and I'm not sure why the game would attempt to chown anything anyway.

There was a time it didn't chown, but then we got this report on bug forum: 46442

Other than that ... I am not sure where "Operation not permitted" comes from. It might come from std::filesystem implementation. I don't know how it is implemented in GCC, but in MSVC version the error texts are hardcoded in the std::filesystem and are not taken from OS (... and it says Operation not permitted to everything ... eg. file doesn't exist? -> Operation not permitted)

[SoShootMe]

Well, the regular Ubuntu update, but I doubt this changes the permissions for my NAS share ... question is how should I set the permissions on this share to allow for Factorio to set the neccessary permissions runtime?

After a fair bit of digging, I can't work out what the Synology software does beyond adding what seems like as many ways as possible for things to not work(!). It's possible (but I would say unlikely) that an Ubuntu update has caused it to trip up. The only further things I can suggest are to look at the ownership of files on the NAS, especially compared with a newly created file, and if that doesn't provide clues that lead you to a solution, try to replicate the errors outside of Factorio and raise in Synology forums.

However, that should be expected and I'm not sure why the game would attempt to chown anything anyway.

There was a time it didn't chown, but then we got this report on bug forum: 46442

No special handling should be needed (or I would say is desirable) in Factorio; it's a sysadmin problem (eg typical "directory writeable by multiple users": have all the users be members of some group, set the directory to that group and mode 2770 (or less restrictive), and use umask 007 (ditto).) The second issue raised of being able to "take over another users save file" is not addressed anyway: to create a file in a directory you need write access to it, but that (normally) also allows deleting files, regardless of the files' owners/groups/modes.

If errors from chown only result in warnings, this is all fairly inconsequential however.

Other than that ... I am not sure where "Operation not permitted" comes from. It might come from std::filesystem implementation. I don't know how it is implemented in GCC, but in MSVC version the error texts are hardcoded in the std::filesystem and are not taken from OS (... and it says Operation not permitted to everything ... eg. file doesn't exist? -> Operation not permitted)

"Operation not permitted" is the typical result of strerror(EPERM); I'd expect it to come from the standard library implementation, but not in std::filesystem. The error from the underlying syscall should work its way up... "Operation not permitted" if a file doesn't exist is surely a bug...