Syncthing creates folders in .stversions with 555 permissions then can't add new folders

[ascend9928 (Will)]

Hi there, I’m using syncthing as (a part of a larger) backup strategy for some laptops. The laptops are Windows, there is then a linux install that has the laptops’ shared folders synced receive-only with staggered versioning.

What I find is I get a lot of errors in some shares like this:

syncing: delete file: staggered versioner: archive: mkdir /__snip__/.stversions/a/b/c: permission denied

I find that .stversions/a/b has permissions 555 (so dr-xr-xr-x). If I manually change them using chmod 755 (or 775), then that error goes away and is replaced with:

syncing: delete file: staggered versioner: archive: mkdir /__snip__/.stversions/a/b/c/d: permission denied

Syncthing created folder c, since it now has permissions in b, but it created c with 555 so now it can’t create new files or folders inside c!!!

The “linux install” is a docker image running syncthing v2.0.10 where the host is unraid. The UID and GID are piped through correctly so that the host and container are using the same user IDs so that user/group chown is correct.

The particular docker image I’m using (because that’s what was in unraid app repo) has support for passing in a UMASK, which doesn’t seem to work as I’ve tried 002 and 022 and never-the-less syncthing still creates folders in .stversions with permission 555.

Does anyone have any pointers on this? I’m going mad. I’m considering just whacking a */5 * * * * find /mnt/user/backups/syncthing/*/. stversions -type d -perm 555 -exec chmod 775 {} + in my crontab but I’d really rather know what’s actually going on…

Other info:

• I tried both ignore permissions on and off, it makes no difference
• I also get a bunch of syncing: delete dir: directory has been deleted on a remote device but is not empty; the contents are probably ignored on that remote device, but not locally

[gadget]

@ascend9928

The UID and GID are piped through correctly so that the host and container are using the same user IDs so that user/group chown is correct.

Note, a container’s namespace is separate from the host’s, so although UIDs and GIDs inside the container might use the same numbers as the host, they aren’t linked.

One easy way to understand it is if the root user (with UID/GID = 0) inside a container has the same privileges on the host as the host’s root user, then it’d offer a simple path to compromising the host since few users audit the containers they download from various websites.

Files created inside a container and saved to a mounted volume shared by the host will be assigned what’s referred to as subordinate UIDs and GIDs.

The particular docker image I’m using (because that’s what was in unraid app repo) has support for passing in a UMASK, which doesn’t seem to work as I’ve tried 002 and 022 and never-the-less syncthing still creates folders in .stversions with permission 555.

For various reasons, syncing directory permissions only works between the same OS.

Because Syncthing is running inside a container, there are two umasks – one inside the container and one outside on the host. One or both might be in play depending on the type of storage.

You didn’t mention if Syncthing is using storage inside the container’s filesystem, a bind mount, Docker volumes or a network share. Which type is used affects how permissions are managed.

• I tried both ignore permissions on and off, it makes no difference

Since you’re syncing between different OSes – Windows and Linx – definitely enable “ignore permissions” in Syncthing.

• I also get a bunch of syncing: delete dir: directory has been deleted on a remote device but is not empty; the contents are probably ignored on that remote device, but not locally

If you’re ignoring files, you might need to add the (?d) prefix to some of your patterns.

[ascend9928 (Will)]

Thank you for your helpful reply, and sorry for my middling Linux knowledge!

I don’t think I have user namespace remapping enabled (is that what you mean by “subordinate UIDs and GIDs” or is there something I don’t yet know!):

# docker info
__snip__
Storage Driver: btrfs
  Btrfs: 
Docker Root Dir: /var/lib/docker
__snip__

I think if user namespace remapping was enabled I’d see that on the “docker root dir” line. I also see both files created inside the container and outside the container as having the expected user/group.

I’m using bind mounts, so docker container inspect syncthing shows:

__snip__
{
                "Type": "bind",
                "Source": "/mnt/user/backups/syncthing",
                "Destination": "/data5",
                "Mode": "rw",
                "RW": true,
                "Propagation": "rprivate"
            },
__snip__

And the host has /mnt/user using a fuse file system:

# mount | grep user
shfs on /mnt/user type fuse.shfs (rw,nosuid,nodev,noatime,user_id=0,group_id=0,default_permissions,allow_other)

So it’s kind of a chain of Container → Docker bind mount → Unraid shfs (FUSE) → Underlying disk