Trouble getting Syncthing's `copyOwnershipFromParent` feature for folders to work

Hello! I’m trying to get Syncthing’s copyOwnershipFromParent feature working.

I’m running Syncthing as a system service with the goal of having Syncthing be usable inside home folders (e.g. inside /home/myuser/) on a multi-user system.

This is with duplication of the permissions of the parent folder, so all files touched by Syncthing in the home folders have permissions mirroring those of their respective parent folders.

I read that Syncthing needs CAP_CHOWN and possibly other permissions for that to work:

I also tried setting Syncthing’s user to root as a workaround with services.syncthing.user, but there was some error that caused it not to work.

I tried to give Syncthing those permissions with systemd.services.syncthing.serviceConfig.AmbientCapabilities, but test folders I created still are owned by the Syncthing user, not by the the owner of the parent folder.

Here’s the relevant parts of my configuration.nix:

configuration.nix excerpts
  # Install and configure syncthing
  # Config pieced together from the following sources:
  #   https://forum.syncthing.net/t/folder-specific-ownership-policy/24921/2
  #   https://nitinpassa.com/running-syncthing-as-a-system-user-on-nixos/
  # Need to manually set default behavior for new folders to inherit ownership permissions from parent folder
  systemd.tmpfiles.rules = [
    "A+ /home/user/ - - - - user:syncthing:rwx"
  ];
  # From: https://github.com/NixOS/nixpkgs/issues/338485#issuecomment-4444976428
  systemd.services.syncthing.serviceConfig = {
    AmbientCapabilities = [
      "CAP_CHOWN"
      "CAP_FOWNER"
      "CAP_SYS_ADMIN" # Probably not necessary, included in case
      "CAP_DAC_OVERRIDE" # Probably not necessary, included in case
    ];
    CapabilityBoundingSet = [  ];
    PrivateUsers = lib.mkForce false;
    ProtectHome = lib.mkForce false;
  };
  #system.activationScripts.script.text = ''
  #  setfacl -m u:syncthing:rwx /home/user/
  #  '';
  #systemd.services.syncthing.serviceConfig.ExecStartPre = "/bin/sh -c \"setfacl -m u:syncthing:rwx /home/user/\"";
  systemd.services.syncthing.serviceConfig.ExecStartPre = "/bin/sh -c \"/run/current-system/sw/bin/setfacl -m u:syncthing:rwx /home/user/\"";
  #systemd.services.syncthing.serviceConfig.ExecStartPre = "/bin/sh -c \"printenv PATH\"";
  services.syncthing = {
    enable = true;
    openDefaultPorts = true;
    settings = {
      devices = {
        # devices redacted
      };
      
      folders = {
        "testfolder" = {
          path = "/home/user/testfolder/";
          devices = syncthing_devices;
          copyOwnershipFromParent = true;
        };
        "testfolder2" = {
          path = "/home/user/testfolder2/";
          devices = syncthing_devices;
        };
      };
      
      options = {
        #defaults = {
        #  folder = {
        #    copy_ownership_from_parent = true;
        #    meow_meow_meow = true;
        #  };
        #};
      };
    };
  };

Much of the Syncthing systemd bits of my config are from here:

1 Like

I am the last post in the github issues; I haven’t been able to test the config yet; but will be doing so soon; the way I set my system up requires me to actually deploy syncthing to two computers first.

I’ll join in on this conversation again in a week; but in the meantime do you see any relevant logs in systemd service?

1 Like

@buterfloro Basically have the same issue; but never saw troubles about setting ownership in the journal logs. I did some digging; and it seems it’s a bug on syncthing side that actually makes syncownershipfromparent completely moot. Copy ownership feature not working with directories and files in it · Issue #8399 · syncthing/syncthing · GitHub

The brain dead workaround I will be doing is a systemd timer that will periodically fix permissions until a fix. This issue has been present for 4 years and haven’t been fixed yet; so I wouldn’t hold out for it. I don’t know go, but will try to learn and submit a fix using ai pair programming at some point; but not any time soon.