Struggles with truenas scale, nfs share permissions and backing up from Linux desktop to NFS shares

Hi,
I’ve set up a basic 2x22tb mirrored VDEV, created the root and a child dataset “nfsshare”, that I’ve assigned as a NFS share and have been able to mount on my KDE plasma, EndeavourOS Linux desktop, having previously created the folder /mnt/nfsshare
sudo mount -t nfs desktopIP:/mnt/pool1/nfsshare /mnt/nfsshare

The aim is to backup my desktops HDD’s to the NAS share, but it’s been anything but easy. By ticking “read” “Write” and “Execute” permissions for “User”, “Group” and “Other”, I’ve been able to copy files to /mnt/nfsshare successfully. If I do this in the dolphin file browser, files and folders can be easily copied across, but file characteristics like creation/modification date and such are not preserved.
I then tried with rsync -a, then ran into permissions issues. I then worked with the following rsync command based on a stack exchange thread.
sudo rsync -rlDtv
This seemingly stripped out permissions issues and I can copy data across whie preserving creation dates and such, but I can’t then edit/delete that data in dolphin, like I could when i simply copy and pasted to the nfs share from within dolphin. Forcibly “sudo rm (file)” a folder in the nfs share mount point gives “rm: cannot remove (file): Permission denied” I’ve tried reapplying the permissions in the truenas dataset, recurisvely as well with the new files and folders without success as well.
Is there some basic networking/permissions knowledge I’m missing? There has to have been a better approach than “add read, write and execute permission to everbody” approach I used at the start as well.

1 Like

For better or worse this kind of backup is often easier when running rsync as root, permissions don’t matter then. Regarding deletion, this is probably due to permissions on the root directory in the share. Try copying to a sub-directory in the share to fix this.

However you might also look at borg backup. Since it backs up to its own database, you don’t have to worry about permissions in the destination share. Plus you can do incremental backups with pruning (keep yearlies + 6 monthlies + 4 weeklies + 7 dailies).

1 Like

Which version of TrueNAS Scale are you using? There was an update where rsync server on the underlying host was replaced by an rsync application from their app store. It might be that?

Ok, Borg looks like a very competent backup solution. May not be right for this stage of the project yet. I’ve got 2 seperate HDD’s with copies of the same files (my old backup solution), I want to copy both sets of files to my NAS, then go through and dedupe them, check hashes etc, generally clean up into 1 master copy. I’ve noticed weird things going wrong with the old data on the more commonly used backup hdd.
Is Borg a program that would run on the NAS. or on my computer which I access the database on the NAS?

On the actual file copying, I can copy files and folders to the nfsshare NFS share dataset (child dataset of naspool1), and files get properly written into sub folders. But I can’t copy into, edit or delete files in folders beneath the root directory of the nfsshare dataset. Is there some magic command I need to run?

I’m running “TrueNAS-SCALE-23.10.2”. I’m just using the rsync command on my linux desktop, pointing it at a local folder then the mount point of the NFS share, beind shared from truenas. Does rsync run on both sides of the connection?

Yeah, sounds like you need to correct permissions on the root folder of the share. If your user can’t write to it you can’t rename, create or delete files.

Ok, thank you, but how do I do this? is this permissions on my computer / my desktop user, or a “user” in truenas permissions?

TrueNAS machine gets requests over the network with uid/gid attached. And maps those network requests to local filesystem requests.

Create a user on TrueNAS with same uid/gid as the one you’re using on the client.

… or maybe try samba instead of NFS - samba handles network identities and their mapping to server native users differently.

1 Like

That’s done the trick, I used the id command in the linux command line, created users and groups with the same ID’s and gave the user access recursively to the dataset in truenas, can now access and edit from my linux file browser, amazing! Thank you very much.

I had looked at SAMBA and actually got it working, but I was trying to find the difference. I couldn’t find much apart from a general “If you’re linux, use NFS. If windows, SAMBA”. Guessing if I want to access from both OS’s, Samba would be better, as linux can speak SAMBA, but windows can’t speak NFS?

These days - 2024, at home, or in small offices, Samba is probably what you want, and probably you shouldn’t bother with NFS.

Leave NFS to people (corporations / governments / universities) who employ dedicated sysadmins, or programers and enthusiasts who like overcomplicating their home networks, and not enjoy spending time playing sysadmin at home instead of being paid for it.