SOLVED Syncthing and existing datasets

[Pycrs]

Hello,
I recently installed Syncthing from the Official charts. I have a pool tank, which contains a dataset data. Under that dataset I have user home directories. Now I want to create a directory in a user's home directory called Documents, which I would like to add to Syncthing. I would probably need to add a host path volume for the container. In this case /mnt/tank/data seems appropriate? (So that Syncthing can sync to all users' home directories). What I'm unsure of is the permissions. Do I use the apps group for the whole dataset or for directories used by ST only? Would I be even going to the right direction with the apps group?

 

[piersdd]

Not directly related to your question, but given I've been hitting my head against this for a few days..

There are a number of different 'chart' implementations Syncthing, with TrueNAS recently pushing their 'Enterprise' train version with;
- Blog - Enterprise File Sync Improves Data Mobility and Furthers Data Freedom | TrueNAS Community, and
- Syncthing | 23.10/scale tutorials
- it is pretty security conscious, and not entirely user friendly, given they disable local and global discovery etc.
- however they makes some opinionated decisions regarding Extended attributes. Which I appreciate, thank you iX Systems. Definitely worth a read

An alternative to the official TrueNAS 'charts' train, is the TrueCharts 'stable' version, which I'm using as it has far more configurable elements;
- TrueCharts | truecharts.org

Not withstanding that difference with your implementation, the following may be of some use;

- Using the latest TrueNAS 23.10 Corbia, 'host-path validation' is no longer a configuration headache (yet still a security concern)
- Datasets support ACLs, even though Syncthing is using UID/GIDs.
- ACL Type: SMB/NFSv4
- ACL Mode: Passthrough (re-check, as this somehow changed to back to Restricted on occasion)
- "..Syncthing records both the numerical UID and GID for a file and the corresponding user and group names, when they are known. When applying ownership Syncthing will first attempt to look up a local user or group with the given name, and if that fails it will fall back to the numerical UID and GID." syncOwnership — Syncthing v1.23.4 documentation
- "..if a file is modified on Linux it’s expected that macOS extended attributes will be preserved in the metadata and hence applied again on macOS. This is not always possible - for example if a file is _moved_ on Linux, the macOS extended attributes for that file will be lost." syncXattrs — Syncthing v1.27.0 documentation
- Nested datasets 'sort of work', for initial sync at least. Moving a file within a client's directory structure (which has no notion of the backing nested datasets) predictably does not move the file into the appropriate sub-dataset. This is I'm sure because Syncthing is clever about moving stuff around on remote systems, to minimise resending data that already exists on the remote system. It tries to 'move' the file which is impossible between ZFS datasets (a copy and delete operation is required).
- I will be ditching my nested datasets, syncing those data that genuinely need that unique ZFS functionality in seperate Syncthing folders

Regarding permissions, and group permissions in particular, I have yet to devise a system for Syncthing in my household. Although shall probably do something similar to my `media` dataset, which uses a new family group, of which the `apps` user is a member.

Probably another good reason to look at the TrueCharts version, as their 'stable' trains include a bunch of standard variables that enhance deployment, such as;
- 'fsGroup': "The group that should own ALL storage, generally 568 but some apps may have specific owners (i.e Nextcloud)"
- 'Supplemental Groups': Add any Supplemental Groups as necessary

 

[dajhorn]

Syncthing running on TrueNAS has two frustrating quirks for new users:

1. The containerized Syncthing cannot traverse datasets.

You must map tank/data into the app container. If you only map tank, then you will get a confusing "permission denied" error for tank/data.

(This is a design choice that is explained somewhere in this forum.)

2. Group membership for Syncthing doesn't work.

If you install Syncthing with default options, then you must apply ACLs for the apps user (uid 951) to each external dataset or you will again get confusing "permission denied" errors.

(This is a Kubernetes constraint.)

 

[Pycrs]

Not directly related to your question, but given I've been hitting my head against this for a few days..

There are a number of different 'chart' implementations Syncthing, with TrueNAS recently pushing their 'Enterprise' train version with;
- Blog - Enterprise File Sync Improves Data Mobility and Furthers Data Freedom | TrueNAS Community, and
- Syncthing | 23.10/scale tutorials
- it is pretty security conscious, and not entirely user friendly, given they disable local and global discovery etc.
- however they makes some opinionated decisions regarding Extended attributes. Which I appreciate, thank you iX Systems. Definitely worth a read

An alternative to the official TrueNAS 'charts' train, is the TrueCharts 'stable' version, which I'm using as it has far more configurable elements;
- TrueCharts | truecharts.org

Not withstanding that difference with your implementation, the following may be of some use;

- Using the latest TrueNAS 23.10 Corbia, 'host-path validation' is no longer a configuration headache (yet still a security concern)
- Datasets support ACLs, even though Syncthing is using UID/GIDs.
- ACL Type: SMB/NFSv4
- ACL Mode: Passthrough (re-check, as this somehow changed to back to Restricted on occasion)
- "..Syncthing records both the numerical UID and GID for a file and the corresponding user and group names, when they are known. When applying ownership Syncthing will first attempt to look up a local user or group with the given name, and if that fails it will fall back to the numerical UID and GID." syncOwnership — Syncthing v1.23.4 documentation
- "..if a file is modified on Linux it’s expected that macOS extended attributes will be preserved in the metadata and hence applied again on macOS. This is not always possible - for example if a file is _moved_ on Linux, the macOS extended attributes for that file will be lost." syncXattrs — Syncthing v1.27.0 documentation
- Nested datasets 'sort of work', for initial sync at least. Moving a file within a client's directory structure (which has no notion of the backing nested datasets) predictably does not move the file into the appropriate sub-dataset. This is I'm sure because Syncthing is clever about moving stuff around on remote systems, to minimise resending data that already exists on the remote system. It tries to 'move' the file which is impossible between ZFS datasets (a copy and delete operation is required).
- I will be ditching my nested datasets, syncing those data that genuinely need that unique ZFS functionality in seperate Syncthing folders

Regarding permissions, and group permissions in particular, I have yet to devise a system for Syncthing in my household. Although shall probably do something similar to my `media` dataset, which uses a new family group, of which the `apps` user is a member.

Probably another good reason to look at the TrueCharts version, as their 'stable' trains include a bunch of standard variables that enhance deployment, such as;
- 'fsGroup': "The group that should own ALL storage, generally 568 but some apps may have specific owners (i.e Nextcloud)"
- 'Supplemental Groups': Add any Supplemental Groups as necessary

Very interesting and helpful read, thank you.

Syncthing running on TrueNAS has two frustrating quirks for new users:

1. The containerized Syncthing cannot traverse datasets.

You must map tank/data into the app container. If you only map tank, then you will get a confusing "permission denied" error for tank/data.

(This is a design choice that is explained somewhere in this forum.)

2. Group membership for Syncthing doesn't work.

If you install Syncthing with default options, then you must apply ACLs for the apps user (uid 951) to each external dataset or you will again get confusing "permission denied" errors.

(This is a Kubernetes constraint.)

This explains a lot of the questions I've been having, tank you so much.

 

[anodos]

Syncthing running on TrueNAS has two frustrating quirks for new users:

1. The containerized Syncthing cannot traverse datasets.

You must map tank/data into the app container. If you only map tank, then you will get a confusing "permission denied" error for tank/data.

(This is a design choice that is explained somewhere in this forum.)

2. Group membership for Syncthing doesn't work.

If you install Syncthing with default options, then you must apply ACLs for the apps user (uid 951) to each external dataset or you will again get confusing "permission denied" errors.

(This is a Kubernetes constraint.)

If you want syncthing process to bypass filesystem permissions you'll want to set relevant capabilities. CAP_DAC_OVERRIDE, CAP_FOWNER and friends. If you're synchronizing the xattrs (and using NFSv4 ACL type), then leaving restricted aclmode is fine, but you should _not_ have syncthing try to synchronize permissions as well. Copying the xattr is sufficient to preserve file mode.

NOTE: this is for SCALE <-> SCALE synchronization.