Dietpi-backup failing when backing up to Netgear ReadyNAS Duo

Creating a bug report/issue

I really want to create a backup of my dietpi installation to my NAS, but can’t.

Required Information

  • DietPi version | cat /boot/dietpi/.version

  • Distro version | echo $G_DISTRO_NAME $G_RASPBIAN
    buster 0

  • Kernel version | uname -a
    Linux avberry 5.10.103-v8+ #1529 SMP PREEMPT Tue Mar 8 12:26:46 GMT 2022 aarch64 GNU/Linux

  • SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3)
    RPi 4 Model B (aarch64)

  • Power supply used | (EG: 5V 1A RAVpower)
    OKDO Raspberry Pi 4 Power Supply

  • SD card used | (EG: SanDisk ultra)
    SanDisk 32 GB

Additional Information (if applicable)

Steps to reproduce

  1. Create NFS mount on Netgear ReadyNAS Duo
  2. Create dietpi-backup config using the NFS mount
  3. Attempt to create back-up

Expected behaviour

Back-up completes

Actual behaviour

Back-up hangs forever.

Extra details

I want to use dietpi-backup to create a backup and then I’ll take that back-up and copy it to the cloud using rclone and b2.

My RPi4 does not have enough space (12GB left) for a back-up (rsync dry-run says 15GB needed). So I tried to back-up to a mounted NAS (Netgear ReadyNAS Duo), but dietpi-backup mandates NFS be used. I created a new NFS mount, which is recognised, but backup never completes.

There are some rsync errors, which it seems to get past and begins copying files before hanging.

rsync: chown [some file] failed: Operation not permitted (1)

I’ve tried to troubleshoot this, but with no success. Previously when using rsync no with dietpi these errors were ignored and the files all copied successfully.

Digging deeper I think there is a sync problem with NFS, but I don’t understand that.
dmesg gives me this

[12568.797732] NFS: Server reports our clientid is in use
[12568.797766] NFS: state manager: lease expired failed on NFSv4 server with error 1

Did you checked logs from NFS server side? Are there any? If found a couple if similar messages on the web. Most of them are talking about lost connections or NFS server reboots.

I’m not sure I can get access to the logs. There was a time I had SSH access to the NAS, but they close that loophole to get access and now I think I’m left with the Web UI.
Let me see if that offers logs and/or if there is a network share with logs available.

Can you access the NAS via simple cp procedures from your Pi without problems?

These are all the logs I can access, there are no errors when I search each one for NFS only start up logging.

afp.log httpd_access.log
boot_info.log httpd_errors.log
command.log hwmon_info.log
daemon.log itunes.log
diagnostics.log kernel.log
disk_identify.log local_commands.log
disk_smart.log mem_info.log
disk_smart_2022_11_13.log memory_spd.log
disk_smart_2022_11_20.log mounts.log
disk_smart_2022_11_27.log msmtp.log
disk_smart_2022_12_04.log network_settings.log
disk_smart_2022_12_11.log nmbd.log
disk_smart_2022_12_18.log partition.log
disk_smart_2022_12_25.log pci_devices.log
disk_smart_2023_01_01.log processes.log
disk_smart_2023_01_08.log raid.conf
disk_smart_2023_01_15.log raidiator_version.log
disk_usage.log remote.log
dmesg.log services.conf
ecounter.log smbd.log
ecounter_2021_05_19_2333.log spool.log
ecounter_2021_07_17_1306.log spool_error.log
ecounter_2022_07_02_0810.log status-old.log
ecounter_2022_10_20_2008.log system.log
ecounter_2023_01_16_1220.log upnp-av.log
enclosure.log usb_devices.log
etc-ls.log usb_storage.conf
fan_setting_last user.log
fan_setting_min volume.log
fs_check.log xraid_config.log

I can copy files and access files on the NFS mount to the NAS fine although I’ve not tried to copy a huge file to stress test it.

There are some rsync errors, which it seems to get past and begins copying files before hanging.

rsync: chown [some file] failed: Operation not permitted (1)

I’ve tried to troubleshoot this, but with no success. Previously when using rsync (not with dietpi) these errors were ignored and the files all copied successfully.

When running dietpi-backup the rsync commands copy files across correctly and I can see them directly on the NAS, but then it hangs.

hmm this usually happen if the NFS share was not correctly setup. Did you tried to create files and change the owner just for testing?

Whilst I can create files I have tried using chown myself. I will try this, thanks.

If you think the share wasn’t set up correctly perhaps I will also create a brand new share that is NFS only and try that.

I also can’t chown

dietpi@avberry:/mnt/readynas/work_nfs $ chown dietpi dietpi-backup/
chown: changing ownership of ‘dietpi-backup/’: Operation not permitted

Ensure you have setup the NFS share on server side with root_squash option.

I was just reading about root_squash.

I’m not sure if I’ll get any options when creating a new NFS share, but will look for them.

Would specifying in fstab uid and gid 0 be helpful if I can change things on the server. I only have a web UI to administer it.

not sure if this will be helpful. Because you still need to have the possibility to change owner. rsync will need to copy all files with current permission and owner, as they are exist on the original source system.

1 Like

Does rsync copy first and then change owner or can it do it in one?
I wonder if not all users and groups with the same uid and gid exist on my NAS and if they did exist chown might not be needed. I can update the NAS with these if needed.
You can tell my knowledge or rsync and NFS is minimal.

Could you post the contents of your exports file (on the NFS server) here?
Could be /etc/exports or files within /etc/exports.d directory.

Thank, StephanStS

For those following, I have managed to gain access to the NFS server via ssh, which I could not do until today.

Here’s the exports file:

johnny:/etc# cat /etc/exports
"/nfs" *(insecure,insecure_locks,rw,async)
"/work" *(insecure,insecure_locks,rw,async)

/work was the original NFS share
/nfs is a new share I created today to see if I could get things working with a freshly created NFS share

Both shares fail with dietpi-backup

try to add root_squash as option to your export configuration and restart your NAS afterwards.

I am using
/mnt/raid *(rw,async,no_root_squash,fsid=0,crossmnt,no_subtree_check)

I did not investigate further, whether a (rw,async,root_squash,crossmnt,no_subtree_check) would be better.

As far as I understand, your NFS setup is done via a GUI without editing the /etc/exports file directly.
Maybe on your GUI you can select some of the options.

I was able to do that, but no change unfortunately.

johnny:~# cat /etc/exports
“/nfs” *(root_squash,insecure,insecure_locks,rw,async)
“/work” *(insecure,insecure_locks,rw,async)

@StephanStS I have now gained access to the /etc/exports file and made the change suggested above by @Joulinar (not success). You use no_root_squash and if I’m understanding correctly it’s root_squash that’s causing my issue, so I will try with no_root_squash this time and perhaps later no_all_squash if that’s valid on my NFS instance.

Success! Thanks for being a great community and helping me work this out.

The root_squash was the problem and I have now updated NFS to use no_root_squash.

johnny:/c/nfs# cat /etc/exports
“/nfs” *(no_root_squash,insecure,insecure_locks,rw,async)
“/work” *(insecure,insecure_locks,rw,async)

dietpi-backup now runs fine and all files are now with user=root and group=root.

I can now continue to back-up to the cloud and my RPi4 config is safer than it was.


If you investigate on this issue a bit more to find a better solution without no_root_squash would be appreciated. As far as I know, no_root_squash is a bit more unsecure. The result could be a point which we could add to a documentation section “hardening NFS” (which we actually do not have, but I’d like to have it).

1 Like