Sunday Live Q&A: TrueNAS, World Backup Day, Immutability, and Related Tech Topics [YouTube Release]

Youtube Releases
1

Additional Resources:

Business Technicalities Channel

https://www.linkedin.com/in/lawrencesystems/

Connecting With Us

Lawrence Systems Shirts and Swag

►👕 https://lawrence.video/swag/

AFFILIATES & REFERRAL LINKS

Amazon Affiliate Store
:shopping_cart: Lawrence Systems's Amazon Page

UniFi Affiliate Link
:shopping_cart: Ubiquiti Store

All Of Our Affiliates that help us out and can get you discounts!
:shopping_cart: Partners We Love – Lawrence Systems

Gear we use on Kit
:shopping_cart: Kit

Use OfferCode LTSERVICES to get 10% off your order at
:shopping_cart: Tech Supply Direct - Refurbished Tech at Unbeatable Prices

Digital Ocean Offer Code
:shopping_cart: DigitalOcean | Cloud Infrastructure for Developers

HostiFi UniFi Cloud Hosting Service
:shopping_cart: HostiFi - UniFi Cloud Hosting

Protect you privacy with a VPN from Private Internet Access
:shopping_cart: Buy VPN with Credit Card or PayPal | Private Internet Access

Patreon
:moneybag: lawrencesystems | creating Tech Tutorials & Reviews | Patreon

2

Syncing TrueNAS with a Non-Root & Non-Sudo User

This is how I’ve been syncing TrueNAS using a non-root and non-sudo user.

Say we want to sync data/documents on a local TrueNAS to data/backup/documents on a remote TrueNAS.

  • Perform the initial sync to the remote TrueNAS as root.

    • This creates the data/backup/documents dataset since root has permission to create datasets on the parent data/backup.
    • Remember to remove the root connection credentials after the sync is complete

  • Set the remote dataset to readonly with zfs set readonly=on data/backup/documents.

    • This prevents files from being modified on the dataset.
    • The sync user that we create later won’t have permission to change this property.

  • Create the (non-sudo) sync user (ex. syncuser) from the remote TrueNAS GUI.

    • Disable password (using key pairs only)
    • Create home directory
    • Set the shell (bash or zsh)
    • Uncheck the Samba Authentication
    • Uncheck the Allow all sudo commands
    • Add the public key for the replication task

  • Set the ZFS permissions for syncuser on the remote dataset with zfs allow -u syncuser receive,create,mount data/backup/documents.

    • Allows syncuser to receive snapshots but not delete, rollback, etc.
    • Prevents syncuser from overwriting the dataset using Replication from scratch with another dataset.
    • In theory (I haven’t tested this) the syncuser does not need to have file permission on the dataset to perform ZFS commands on it. For example, root can own the dataset and syncuser would get permission denied when trying to access it, however syncuser can still receive the ZFS sends from the replication task.

  • Update the replication task to use the syncuser account.

    • Uncheck Use Sudo For ZFS Commands
    • Destination Dataset Read-only Policy = IGNORE (we already set this manually as root earlier and syncuser doesn’t have permission to change it).
    • Snapshot Retention Policy = None (the syncuser doesn’t have permission to delete snapshots).
    • Note: the TrueNAS replication task will finish with a warning icon next to the Finished badge in the GUI and the logs will say something like cannot receive mountpoint property on data/backup/documents: permission denied. This is due to the limited permissions that we gave to syncuser, but the replication was still successful. If you want to get rid of this warning, you can add the permission to syncuser to read this property with zfs allow -u syncuser mountpoint data/backup/documents.

Downsides

  • You’ll need to create a cron task to cleanup the snapshots on the remote TrueNAS since the syncuser doesn’t have permission to do it via the Replication Task in TrueNAS. Not ideal, however the TrueNAS GUI doesn’t let you create a separate periodic snapshot task for only deleting snapshots.

  • I use syncoid a lot, so maybe this doesn’t apply to TrueNAS replication tasks but if the replication gets interrupted (power/internet outage) you may need to manually delete the in-progress partial %recv snapshot on the remote TrueNAS (since syncuser doesn’t have permission). This allows the replication to start over from the last snapshot. Sometimes it’s able to continue though, so it’s kind of hit or miss.

Testing

Trying to destroy the backup with the syncuser account.

# switch to syncuser
sudo -u syncuser /bin/zsh

# try to delete a file
 % rm /mnt/data/backup/documents/notes.txt 
rm: cannot remove '/mnt/data/backup/documents/notes.txt': Read-only file system

# try to disable readonly
 % zfs set readonly=off data/backup/documents
cannot set property for 'data/backup/documents': permission denied

# try to destroy the dataset
 % zfs destroy -r data/backup/documents
cannot destroy snapshots: permission denied

# try to destroy a snapshot
 % zfs destroy data/backup/documents@snap
cannot destroy snapshots: permission denied

# try to rollback a snapshot
 % zfs rollback data/backup/documents@snap
cannot rollback 'data/backup/documents': permission denied

# logs from trying to overwrite the dataset with another replication task
send from @auto-2024-04-01_01-05 to data/junk@auto-2024-04-01_01-10 estimated size is 624B
total estimated size is 624B
cannot unmount '/mnt/data/backup/documents': permission denied
cannot receive incremental stream: most recent snapshot of data/backup/documents does not
match incremental source
cannot unmount '/mnt/data/backup/documents': permission denied.
1 Like
3

You can also flip this around and create a PULL configuration instead of a PUSH configuration by creating the non-sudo syncuser on the source TrueNAS with the following ZFS permissions:

zfs allow -u syncuser send,hold data/documents

These permissions would allow the user to only send snapshots to the remote TrueNAS. The user would not have permission to destroy the dataset or snapshots. However, if the user has permission to write to the dataset, it could overwrite the files BUT it wouldn’t be able to destroy the snapshots so you could always rollback if you caught it in time.

This may be easier to setup and would also remove the need for the snapshot cleanup cron task. The source TrueNAS would have a Periodic Snapshot Task that creates the snapshots for the destination TrueNAS to PULL. The destination TrueNAS’ Replication Task would connect as syncuser to perform the PULL but have root permissions locally to cleanup the snapshots (using Same as Source).

1 Like