Change:
Describe the bug Folders in syncthing are not accessible to anyone. To Reproduce Steps to reproduce the behavior: syncthing via a folder to be shared Expected behavior The folder is available to everyone in the group under . Additional context The rights to seem to be "user can read/write, everyone else cannot do anything" which doesn't work. Setting results in to be for the user "237" in my case, and I still cannot access it. Also, the syncthing version is very old and not the latest stable. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
ping
Regarding the permissions, this came up before and the problem is the syncthing home directory is created with , so even if owned by the syncthing group you can't access it (see ). This could be solved by a and an ACL rule for default file mode.
hmm, never thought about having a shared folder in /var/lib/syncthing. Is that a usecase? why not have it inside your HOME or some other place? maybe there is a way to change the default sync folder directory to something else.
Apparently it is, the user in was doing exactly this.
Which user are you running as in the case you have the shared folder in your HOME directory?
I run it as the user syncthing. I have 711 permissions on my home. the synced folder has the permissions and the group
ah nice, thanks.
Uhm, my plan doesn't exactly work. By using those ACLs I can get syncthing to create new shared folders with the correct ownership and file permissions: syncthing:syncthing 664. However, if permissions syncronization is enable and a remote node add a new file with 640, the local syncthing group won't have read access, though it owns the file.
I set which works fine when I set my
generally speaking you shouldn't run non user level services as regular user accounts... Some NixOS modules are bad at all but promoting that sort of thing :worried:
Yeah, if you're running it as your user you better be enabling the user service instead (not the system-wide service).
there is no way to configure the user service with nixos? Actually I also have to fix permissions of the created files with inotify, because syncthing can't create them as my user if it runs as another user. A workaround for that would be to let syncthing run as root or with capabilities like . Or as suggested running it as your own user.
Maybe it was a bad assumption... but I just assumed there was a home manager service. I don't use home manager, so don't know. Is there?
there is a home-manager service, but it lacks the very cool feature. What is actually the problem with running systemd-services as normal users? I do this actually often, since I'm unhappy I can't depend on system services with user services.
I'm not saying you can't, but some problems seem to creep up once in a while when people do that. I'm trying to find a few conversations that have discussed this, but can only find one reference at the moment: If a service is going to be running as a regular user conceptually it just makes more sense to run as a user service or home manager module. So can the options be ported to home manager?
well it depends on the usecase. the service can only be run once per system. I use it to manage a lot of different users at the same time. So home-manager wouldn't fit my usecase. porting it to home-manager should be possible if people want to run it as their own user. sadly code would be duplicated in both projects then.
I don't see any problem running the system-wide service as another user than and in another home folder than . Maybe instead to keep code in sync with home-manager, a flag like to start the service as instead of is a simple fix.
The way to think of the current nixos syncthing module as that of an appliance. If you want to run a vm/container/thing somewhere that acts as a server, you would use this module. For actual interactive users, home-manager or home-rolled is the way to go.
Possible workaraound for the 700 issue above: If syncthing creates files with g+rw then users can simply join the syncthing group. Some special bits need setting g+s in the shared folders to keep things tidy. syncthing keeps permissions tight on the config file so rather than fight it, this script helps:

Discussion:
let common = { stname, target, postInstall ? "" }: buildGoModule rec { <del> version = "1.3.4"; </del> <ins> version = "1.6.1"; </ins> name = "${stname}-${version}"; src = fetchFromGitHub { owner  = "syncthing"; repo   = "syncthing"; rev    = "v${version}"; <del> sha256 = "076k06p2vqqz2r5bgvqkjipnhznbfbalp3pa2gjm2j9hy7nldr9f"; </del> <ins> sha256 = "1lhbx1mh2hdjjwks3s17i8y9vbl3fnapc1czaf42pp7nf8245q3j"; </ins> }; <del> goPackagePath = "github.com/syncthing/syncthing"; modSha256 = "10fgfjip5xr8lim2z0dh7399xpcnhxis9s9yd36fk934h1k1hwzd"; </del> <ins> vendorSha256 = "12g63a6jsshzqjgww792xmvybhfbkjx5aza4xnyljjsp453iky7k"; </ins> patches = [ ./add-stcli-target.patch