TrueNAS to TrueNAS Dedicated User Replication documentation for TrueNAS 12

[aaaskew]

I have been trying to find the reason why TrueNAS 11.2-U8.1 was the last release with official documentation for TrueNAS to TrueNAS replication using a dedicated user rather than requiring root access on the target system.

• Last documented at '7.4.3. Example: TrueNAS® to TrueNAS® Dedicated User Replication' (https://www.ixsystems.com/documenta...truenas-to-truenas-dedicated-user-replication).
• The web interface and documentation seems to have changed in TrueNAS 11.3-U2 with no reference to this option at '6.6. Replication' (https://www.ixsystems.com/documentation/truenas/11.3-U2/tasks.html#replication).
• The current TrueNAS 12 replication documentation under 'Advanced' (https://www.truenas.com/docs/core/tasks/replicationtasks/advanced/) has no reference to this setup either.

Is there a post some place that explains why this is no longer a reasonable thing to do? To my mind it appears as if this ability is still useful and not replaced with another method that I can find. In my case I would like to backup my TrueNAS system to my brother and vice-versa without him having access to my files and more importantly, without me having root access to his TrueNAS system.

To see if this was still possible, I have setup some test TrueNAS systems in VMs and done the following:

1. Added a 'Tunables' SYSCTL vfs.usermount=1 on both TrueNAS systems
2. Created a different replication user on each TrueNAS system to allow remote access to the other TrueNAS system. The users has 'Disable Password' set to YES and 'Microsoft Account' and 'Samba Authentication' where not checked.
3. The 'SSH Public Key' of each user was set to the 'Public Key' of an 'SSH Keypair' from the opposite system.
4. An 'SSH Connection' was setup on each system for the opposite system.
5. Each system has an encrypted filesystem (e.g. truenas1pool/truenas1home and truenas2pool/truenas2home). I used passphrases for the encryption.
6. An empty filesystem was created on the opposite system to hold backups (e.g. truenas2/truenas1backup and truenas1/truenas2backup)
7. On the command line, the following was run to allow access for the remote replication users:
   
   truenas1:
   zfs allow -ldu truenas2user create,destroy,diff,mount,readonly,receive,release,send,userprop,aclmode,copies,xattr,sharenfs,sharesmb,mountpoint,hold,reservation,quota,refreservation truenas1pool/truenas2backup
   
   truenas2:
   zfs allow -ldu truenas1user create,destroy,diff,mount,readonly,receive,release,send,userprop,aclmode,copies,xattr,sharenfs,sharesmb,mountpoint,hold,reservation,quota,refreservation truenas2pool/truenas1backup
   
   This command was chosen after trying out the TrueNAS 11.2-U8.1 command and then looking at debug replication logs to try and remove as many errors as possible. There is still an error with sharesmb that I don't understand:
   
   DEBUG [replication_task__task_4.process] [zettarepl.transport.ssh] Success: 'cannot receive sharesmb proper....to set this property or value\n'
   
   Can someone tell me why this log appears, even if I add sharesmb to the 'Properties Exclude' field of the replication task?
   
   
8. Create 'Periodic Snapshot Tasks' for the truenas1home and truenas2home filesystems
9. Create 'Advanced Replication Tasks' using SSH access to the opposite system. (e.g. Source: truenas1pool/truenas1home, Destination: truenas2pool/truenas1backup/truenas1home, 'Full Filesystem Replication', select the associated 'Periodic Snapshot Task', 'Save Pending Snapshots', 'Destination Dataset Read-only Policy' SET, 'Encryption' un-checked (this appears counterintuitive but appears to be the correct thing to do as the source filesystem is already encypted and does not need to be encrypted again!), 'Syncronize Destination Snapshots With Source', 'Snapshot Retention Policy' Same as Source, 'Run Automatically'.
10. Wait for the snapshots tasks to trigger and see that the filesystems and snapshots are replicated to the other TrueNAS.
11. Note that the receiving TrueNAS will see the incomming filesystems locked with the same passphase as on the source system.

I also tried creating a 'RESTORE' 'Replication Task' based on the outgoing task. I could not get the 'RUN NOW' to work until I had marked the task as 'Enabled'. Is this a bug? I would have thought that a one-off restore task would not need to be enabled to run it once. At least the error message when the task was disabled was not clearly pointing to the fact that the task was not enabled.

Has anyone else tried this in production yet? I want to make sure this works before I commit to this way of doing things.