If I have 3 devices: an iPhone, a Linux server and a laptop. There is no suitable iPhone app for syncthing. So, iPhone syncs to the server by WebDAV. The server syncs to laptop by syncthing. The problem is permissions are messed up.
Each device has a bunch of users and processes involved with creating and deleting the files in the shared folders. For example, on server , syncthing creates new files under the user that runs syncthing, and WebDAV under the WebDAV user. How should I set the user and group permissions on each device?
Does any one know a good tutorial, that simplifies this?
Do I need setfacl for this, or could be done with standard Unix permissions?
I created a group mygroup and had WebDAV and syncthing user be members of this group. I set permissions so that newly created files have ownership :mygroup and permission 770. But syncthing crested new files with ownership syncthing_user:syncthing_user with read only group permission. The WebDAV user then cannot delete those files. I get out of sync problems.
There are two good iPhone apps that use syncthing at their core.
Synctrain and möbius sync. They operate substantially differently and each have their pros and cons.
Check them out if youâre interested. Sorry Iâm not directly answering your permissions questions. My permissions situation is very simple so I donât have anything to offer.
Have you turned off Ignore Permissions on the Folder?
What users own the Syncthing process on each Device? What user are you using for the WebDAV component?
Ideally the Syncthing user and the WebDAV user (if they are not the same exact user) should have full read/write access to everything they would touch.
Linux Debian on server, I have a mix of different operating systems on desktops: macOS, windows and one Linux desktop VM.
Yes, I enabled and disabled ignore permissions.
I created dedicated users for syncthing that run syncthing binary on each machine. The WebDAV user is different.
The issue is the WebDAV and syncthing user permissions donât play well with each other on the server, so that they exclude each otherâs access. I created a group and let both users be in this group. The default group for the parent folder is set so that this group owns newly created files, and the default permissions is set such that newly created files have 770. But sometimes the syncthing doesnât respect this: it creates files owned by the primary group of the syncthing user and/or with 640 permission.
I saw in some posts that sometimes syncthing does not respect umask. So if umask is 002, new files must have 775 permission, but syncthing may create files with 640.
There were a couple of posts that Synctrain calls strange places. Probably itâs justified, and maybe it was responded to. Iâm waiting for the app to be trusted by the community. A bit risky.
I created system-level systemd units, specifying user directive. Looking at the processes running, the syncthing executable runs under correct user.
If I create new files manually on bash, new files have correct ownership and permissions expected from default group and umask. But if syncthing process creates new files under exactly the same user, ownership and permissions are different.
I will try today specifying umask 002 in systemd unit as well, see if I can force 775.
The reason for new user was, I run multiple instances of syncthing. Here is the usecase: the untrusted node feature is per instance not per folder. I wanted to have encrypted and non encrypted folders on the server. Also, with encrypted instances, WebDAV is not involved, so itâs better to separate the instances to avoid WebDAV potdbtal issues affecting non encrypted instance.
Also the isolation is good.
These issues would have not been there if there were good native phone apps. Because of that, Iâm forced to use WebDAV to sync phones. Then it becomes a self cooked solutions with permission conflicts between WebDAV (run under caddy user) and syncthing users
Have you thought about moving both caddy and syncthing user accounts to the same group, as their primary group? Like not adding to it in /etc/group, but making it their primary group in /etc/passwd? That should affect which group is recorded as owner for new files created by that user.
Also you should probably enable the âIgnore Permissionsâ option in Syncthing on the server, so it wonât try to chmod the files at all (thus using the umask).
Note that correct ownership is half of it, the other half is syncthing process respecting permissions, granted to the primary group, set by umask, particularly allowing write access by the primary group. Otherwise, files deleted on the phone come back after a few seconds.
I set the user and group under which the syncthing and caddy run to be the same in systemd units, and set umask 002 in both services.
I also set the default user and group using setfacl for the shared folder to be the same also.
It is behaving better now. I will have to run more tests.
There were errors that syncthing cannot chmod the .tmp files that were owned by caddy. I manually deleted them and waiting to see similar errors will arise again.
Itâs because during a shell session, you went thru the login process, picking up the umask on the way. But Syncthing running as a service, thereâs no shell.
Iâve seen that Reddit post and replied to it. I found it rather disingenious, as it provides very little detail (just enough to make an accusation but not enough to actually verify that claim). The author for some reason seems to assume that Synctrain has surreptitious access to the iOS keychain or stored passwords (which it doesnât - and if that were even possible, it would be a major security problem on iOS!).
It is expected for Synctrain (or rather: Syncthing) to talk to various IP addresses when relaying, STUN, NAT-PMP, local discovery and/or global discovery have been enabled. If you disable all of these, you should see connections only to the IP addresses of the peers you configured. This is no different from Mobius or âvanillaâ Syncthing. Synctrain does not make outgoing connections by itself, this is only done from inside the Syncthing code it embeds.
Additionally, the full source code for Synctrain is available here.
Of course you would have to trust that the code in the App Store version matches that code (if you donât, you could build the app yourself - and observe the same behaviour!). I must add that with Mobius you have the same trust issue, but no source code.
More generally, if you use Synctrain, Mobius or Syncthing at all you are putting your trust in its maintainers and those of the various packages used by Syncthing (here is a nice list for Synctrain including Syncthingâs current dependencies).
