Large folders created with different permissions than small

Support
1

I am really confused now, let’s see if this might be something simple on my side, or if it is a bug/oddity in Syncthing.

Background:

I have a setup that can be simplified to a windows laptop and a debian file server, and I have recently started to see problems when folders created by Syncthing are lacking write permissions for group.

After testing a lot of different cases to isolate the problem, I have found one case that I’d really like to see explained, and also see if this is a bug.

  • On the Windows side I have Windows 11, Syncthing 2.0.10.
  • On the file server I have 64-bit Raspberry OS (Debian) and Syncthing 2.0.10.
  • They share one folder. It has “Ignore permissions” set on both sides, otherwise defaults. They are on the same Wifi.
  • On the Debian side, the folder is on a ZFS volume, and has permissions 2775. SGID and g:w is important, because I have other users that needs to be able to manipulate the files and folders.
  • Initially the folder is empty on both sides.

Then, on the Windows side, I create two subfolders, “Test Small” and “Test Big”. “Test Small” contains one file, 3MB. “Test Big” contains 1300 files in 1200 folders, 2GB.

I wait for them to get synced, and when they are, “Test Small” has permissions 2775 (group:rws), but “Test Big” has 2755 (group:r-s), i.e, it has lost write access for group.

In my investigations I first suspected the UMask and did everything I could to set it to 0002 (OS default is 0022). But then I found this post, which says that Syncthing’s default permissions for folders are “a conservative default”, and no matter the UMask, I can’t get write permissions for group.

But in that case: why does “Test Small” get group:rws?

2

This only happens for directories, not for files.

It sounds a lot similar to Issue #9626, but a) that one is completed, and b) here we see a difference in behaviour depending on the size of the folder contents.

3

If anyone has any suggestions for how I could isolate the problem, it’d be appreciated!

Does Syncthing even set the permissions explicitly (@calmh’s comment on the other thread seems to indicate so), or is it somehow left to the OS?

Could zfs somehow be the culprit? I used to have the same setup without problems, and then I rebuilt the server with 1) 64-bit OS, 2) zfs instead of ext4, and 3) Syncthing 2.x instead of 1.x.

4

I wasn’t able to reproduce what you’re seeing on your system.

With “ignore permissions” enabled in Syncthing, it’s ultimately the OS and filesystem. On a Linux system, it’d be a combination of umask, Unix permissions and access control lists.

Probably not. ZFS is just responsible for storing the metadata.

Individually, none of the above stands out as a culprit. I’ve got a mix of ZFS, XFS, ext4 and Btrfs and haven’t had any issues with permissions.

For the usage scenario you originally described, access control lists often works better than regular Unix permissions.

With ext4, there’s nothing else to do except use the getfacl and setfacl commands to view and set permissions. But with ZFS, you’ll have to set the ACL type to posixacl on the intended filesystem, then reboot for it to take effect.

1 Like
5

Ok, thanks for the tips. I might try to see if enabling ACLs could help me. Previously, I figured it would only make the issue more complex, but if I can’t find the problem, it might be a way around it. I will also see if there might be something Raspberry OS-specific about it. Which OS did you try to reproduce it on?

6

Off hand, I can’t think of a reason an RPi could cause what you’re seeing since it’s basically Debian with some additional drivers.

I tried it on Fedora, Debian and Arch Linux.

7

Wow, thanks for doing all that work!

I can’t shake the feeling that I am missing something simple here, I just can’t figure out what.

8

This is so crazy!

I realized that samba was running on the share, shut it down, but still the same results.

Then I tried to figure out at what size the error occurs, and discovered I could remove data from the large folder all the way down to almost the size of the small folder while still losing the permission.

I kept moving a folder with files in it beween two parent folders, each time resetting permissions and allowing syncthing to settle. And when the size was circa 4MB, I could move it without losing permissions if I waited for syncthing to react to the filewatcher and sync.

But if I moved it and immediately pressed “scan” in the synthing UI, it lost the permission in the move!

So my guess it has to do with syncthings way of moving; if it detects a “move” or if it becomes a delete plus a create.

I guess. Does that give anyone any clever ideas for further investigation?

9

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