Keeping assets +r attribute after upgrade 1.30 to v2

Support Android
1

Hello, I’ve got a question - I was using v 1.30 on Linux as a server and decided to upgrade to v2. From now on as I can see clients are still synchronizing since all of them have already v2 installed but filles are not receiving +r attribute anymore.

I mean :

-rw-r--r--  1 root root    4907757 Sep 13 18:20 IMG20260913182023.heic
-rw-r--r--  1 root root    6016849 Sep 13 18:20 IMG20260913182030.heic
-rw-r--r--  1 root root    2771209 Sep 15 19:06 IMG20260915190612.heic
-rw-r-----  1 root root    1151871 Sep 15 19:56 IMG20260915195626.heic
-rw-r-----  1 root root    3029840 Sep 15 20:40 IMG20260915204009.heic
-rw-r-----  1 root root    1916620 Sep 15 20:44 IMG20260915204407.heic
-rw-r-----  1 root root    1050611 Sep 15 20:55 IMG20260915205510.heic

I was searching for setting via Default Folder Settings - Ignore rights and also via advanced settings with copy from parent / Ignore perms / send Xattrs - nothing helps

chmod +r via crontab is not a solution as assume

Syncthing is being used in a lxc unpriviledged containter on proxmox with local root privileges.

What am I missing? Thnx in advance

2

Just a note, as I think there may be some confusion here, the Default Folder Settings are only applied when creating new folders. Even if you change them later, that will not affect the already existing folders. Those need to be modified individually.

3

Anyone have maybe this issue as well? When I’ve created new folder to be synchronized it is also not receiving +r attribute even when I’ve checked to “ignore permissions” in Advanced. Source doesn’t matter - assets are coming from Android, Win with the same issue.

4

If you’re running with ignore permissions enabled this is controlled by your umask.

5

Indeed that what I was wondering - but umask on both (local host root and container root) are by default 0022 so should be readable for everyone.

6

I don’t know much about LXC containers, but that’s the first suspect I’d investigate in your case. Make sure to check the umask in the same execution context as Syncthing runs in.

The other idea depends on how you start Syncthing inside the container. If systemd is involved, some recently added hardening options in our template unit files might be at play?