Syncing error "setting perms on temp file: operation not permitted"


first of all, that’s my storage setup:

Storage Server hosting SMB share > SMB share mounted on Application Server > Syncthing as Docker Container (SMB share from host passed through as docker volume)

Now on that Syncthing instance I get an error in the WebUI when new files are synced to it:

operation not permitted:
syncing: setting perms on temp file: chmod <pathtofile>/.syncthing.<filename>.tmp: operation not permitted 

I could find out that the permissions on that shared directory (inside the syncthing container) are: drwxrwxrwx 2 root xfs 0 Jul 24 19:45 /datadir

For the files inside that directory it’s the same. For one of the files in the error message shown at the beginning the permissions are:

-rwxrwxrwx 1 root xfs 433K Sep  2 11:16  .syncthing.<filename>.tmp

That xfs group seems a bit suspicious to me but at the end it should be rwx for everyone, right?

Any ideas where this permission error comes from?

The only similar thread I could find is this one, but I don’t really understand how it was solved there.

EDIT: Just realize I’m using this (Docker Hub) docker image, because I’m used to the images (as regularly updated and all with consistent dockercompose files).

On syncthing/ at main · syncthing/syncthing · GitHub there’s written:

Use the /var/syncthing volume to have the synchronized files available on the host. You can add more folders and map them as you prefer.

But this seems to be something else, doesn’t it?

Just a general point: That’s going to be inefficient, as in likely super slow. Ideally you run Syncthing on the device that actually has the data locally.

Most likely samba doesn’t allow permission operations. The example you showed makes it look like it’s been mounted with the option to just show all permissions as 777. Unless you do manage permissions between whatever is behind SMB, in SMB itself and locally, setting syncthing’s “ignore permission” option is likely what you want to do.

Thank you @imsodin! I’m not quite sure what you mean with “permission operations” but you’re absolutely right, samba does have some kind of issue with that … Setting the “ignore permission” option indeed solved the issue!

As for the performance side of things: Also thanks for that … I’ve thought about that aspect in the past but having a separate storage device/server from the actual “application server” shouldn’t be rare at all, right? Eventually there’s some better solution, if someone has experience/knowledge in this field please share it!
Creating a SMB share just seemed as the best solution to me, as e.g. NFS (whoose performance probably is roughly similar) doesn’t bring any good authentication system (apart from IP restriction) with it.

“Permission operation” as in setting permissions :slight_smile:

Indeed that’s not rare, though Syncthing is a storage application thus should run on the storage server. You can still use smb for whatever else you are running on the app server. There might be some more performant options than smb or tweaks of it’s config, but it won’t change the fundamental issue: Interacting with a filesystem over a network will always be a lot slower than local access.

Ok, thank you for the follow up! I’ll consider some kind architectural change in the future to prevent this bottleneck …

Just to clarify: I am not saying it’s not possible, I am certain people are doing it. It’s just not recommendable in my opinion.

Of course imsodin … and there’s definitely validity to your criticism.

EDIT: I know there are tons of variable factors to this but how would the performance aspect be with SMB, thus storage over network but we assume both servers are on the same hardware server, e.g. two virtualized VMs?
This would mean the speed relies on internel bus connections, etc. Could it perform similar to Syncthing “directly” on the same OS/filesystem?

Maybe, don’t know how much overhead that adds. As you say, depends on the type of VM etc. I’d just try it out.

Ok, thank you for the support and ideas.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.