Dietpi-backup failing when backing up to Netgear ReadyNAS Duo

My thoughts are that dietpi-backup wants to change ownership of all files on NFS to root, which isn’t allowed unless you relax security on the Netgear ReadNAS Duo. This is because the only remote backup supported is via NFS.

It may be possible find a more restrictive security solution than just going with no_root_squash, but that still leaves NFS as the only remote solution. What about using additional shares like CIFS/Samba etc.? What about using additional tools like rclone to allow cloud backup to Backblaze B2 and Google Drive, etc.?

My challenges were trying to get legacy hardware and OS to make NFS work because of NFS being the only option, which would not have occurred if I could use other options.

I’ll update you if I find a better way to do NFS backups; can you consider other backup options also?

This is not correct. Our tool is trying to set all permissions same way as they are on the original source system. This could be any user/group. Therefore it is mandatory to have the possibility to change ownership.

SAMBA is not possible as it doesn’t support Linux file system permissions at all. Therefore, we allow NFS only as backup target location.

Again, the challenge is with file system permissions. To be able to backup to a remote cloud location, we would need to create a tarball first (to keep permissions) and upload it afterwards. There you would need to end up on similar challenge as you need required space to be able to create the tarball.

You are right. However, a lot of the files, but not all, are owned by root and it’s changing to root that’s the problem as I understand it.

Thanks for your explanation of why the other options do not work. I suspect my backup to B2 (so I have my backups in multiple places) is not going to work then as although it preserves symlinks I don’t believe ownership is preserved.

it is the possibility to change owner in general not for root user explicitly.

Yes, you need to preserv file system permissions as well as symbolic links. Therefore, a tarball is needed. Otherwise, you will lose restore possibility. Better to say, a restore might going to work but probably the system will not be able to start up again.

You are right, I was thinking back to when I first diagnosed this as the need to chown and I had only seen root as a user that was being done with. There are of course other users that need to change owner.

Aha! So, if I then create a tarball of the back-up and then upload this to B2, instead of the whole set of back-up file with specific owners etc., I should be okay. I just need to add an additional step I hadn’t thought of. Thanks.

A further update.
rclone offers --links and --metadata flags so you can back-up symlinks and permissions with your files to systems that don’t support them and restore them to systems that do support them.