FreeNAS Syncthing plugin permissions strangeness

Hi all!

I have a strange Syncthing plugin problem on FreeNAS.

I’ve created a separate ZFS dataset (think of it as a drive partition) for syncthing. When creating a dataset, you can choose for it to use either Unix permissions or ACLs.

Since FreeNAS plugins run in FreeBSD jails, its users and groups are separate from base system’s users and groups. In addition to that, any storage external to a jail must be explicitly mounted.

There are several approaches in setting permissions to make mounted storage available to jail users. The one I use in this scenario is to have a group in the base system (e.g. backup, GID=1003) and set desired permissions on the directory in the base system. Then, create a group with the same GID in the Syncthing jail and add the syncthing jail user to that (jail) group. That way, base system’s group permissions effectively get propagated to the same group inside the jail.

Now, I have a Win10 laptop with syncthing running (already syncing a few directories to an RPi). I’ve tried sharing two directories with the FreeNAS Syncthing instance (one is my Documents directory, the other one the phone photos directory already synced with my Android phone)

Initially, I’ve only created the sync dataset on FreeNAS and let Syncthing create a top-level directory when creating each share (documents and phone_photos)

If the sync dataset is created with Unix permissions, everything works as expected.

However, if I create the sync dataset with ACLs (Windows permissions), the phone photos share gets synced properly, but the documents share fails with an error like finisher: chmod /mnt/bozho/documents/My Games/Borderlands/WillowGame/Logs/.syncthing.Launch-backup-2017.03.13-21.56.32.log.tmp: operation not permitted for every file. All subdirectories under documents get created.

getfacl on documents returns:

# file: documents/
# owner: syncthing
# group: backup

phone_photos (the one that gets synced properly) has the same permissions, as does the Logs directory with the .tmp file.

getfacl for the .tmp file returns:

# file: .syncthing.Launch-backup-2017.03.13-21.56.32.log.tmp
# owner: syncthing
# group: backup

Files in phone_photos have the same permissions.

Any ideas what might be happening here?

Thank you

Huh, while I did find the first and the third link, I missed the second one somehow, thank you!

The confusing thing is that sync works on the same dataset for my phone photos directory (those are receive-only on my laptop) and they are synced to FreeNAS only from my laptop as receive-only (haven’t added my phone to the FreeNAS Syncthing).

I just tested and ignoring permissions on the documents on the FreeNAS Syncthing made it work. The phone_photos directory on the FreeNAS Syncthing does not ignore permissions and is working fine. Is Syncthing not trying to chmod these files because their original source is an Android phone?

The only difference I found was that phone photos on my laptop inherited permissions from my home dir and files in the Documents directory had explicit permissions set.

I then made sure that my home dir and everything in it is owned by me and reset all the permissions on files and directories in the home dir to inherit from the home dir. Made sure that files in the Documents directory inherit permissions.

Then I removed both shares from the FreeNAS Syncthing, deleted both directories from the FreeNAS storage and re-added both shares (not ignoring permissions on both). Phone photos share synced without problems, the documents share keeps reporting failing chmod.

Syncthing requires chmod to work, if it does not work on your platform, I can’t predict what the behaviour will look like.

I understand that, but the confusing thing is that it does work for one shared folder, but not the other (on the same system) - that’s what I’d like to figure out.

Edit: Is there a scenario where Syncthing would not call chmod, which could explain the phone photos share working?

Not really, I think it calls chmod on all operations to make sure the directory its working in is writable.

Then does chmod based on wether permissions are ignored or not.

I think, the Android App still “enforces” ignore perms, so at least the remote (from the NAS side of view) has ignore perms, and so maybe does no chmod or does something different then if it wasn’t set.

I’m not syncing directly with the phone, I’m only sharing from my Win10 laptop to FreeNAS. Could that setting be implicitly transferred, too?

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