recover of backup failed

[miloit]

Details:

• Date | 2025-11-16 15:49:04
• Program name | DietPi-Backup
• Command | cp -a /mnt/nfs_client/dietpi-backup/data/etc/debian_version /etc/debian_version
• Exit code | 1
• DietPi version | v9.19.2 (MichaIng/master)
• Distro version | trixie (ID=8)
• Kernel version | Linux DietPi 6.12.57-current-rockchip64 #1 SMP PREEMPT Sun Nov 2 13:15:23 UTC 2025 aarch64 GNU/Linux
• Architecture | arm64
• Hardware model | NanoPi R5S/R5C (aarch64) (ID=76)
• Power supply | (EG: RAVPower 5V 1A)
• SD card | (EG: SanDisk Ultra 16 GB)

Steps to reproduce:

1. ...
2. ...

Expected behaviour:

• ...

Actual behaviour:

• ...

Extra details:

• ...

Additional logs:

cp: preserving permissions for ‘/etc/debian_version’: Operation not supported

[MichaIng]

Can you show the output of this:

ls -l /mnt/nfs_client/dietpi-backup/data/etc/debian_version /etc/debian_version

And what filesystem type is used on the NFS server side? Are you using recursive ACLs or xattr there?

Generally, the restore was mostly complete, rsync copied all files it found a diff. The reason we copy /etc/debian_version manually afterwards, is that it can have the same size and mtime between Debian versions, and hence rsync might think it is identical, not copying it, during backup, or restore, or both. So we copy it manually in both cases after the rsync call. This is however relevant only for the first backup after a distro upgrade, or when restoring an older Debian version after a distro upgrade.

But that cp -a fails indicates that there seems to me some limitation regarding NFS in combination with a certain filesystem type or maybe certain attributes on the server side. If NFS is used, we cannot know which filesystem type the server uses, hence we test changing the mode of a test file via chmod back and forth to see whether the changes are effectively applied, to assure the server side has UNIX mode support. Looks like this test is not sufficient in all cases.

[miloit]

 ls -l /mnt/nfs_client/dietpi-backup/data/etc/debian_version /etc/debian_version
-rw-r--r--  1 root root 5  7. Nov 18:40 /etc/debian_version
-rw-r--r--+ 1 root root 5 24. Aug 18:20 /mnt/nfs_client/dietpi-backup/data/etc/debian_version

And recursive ACLs

[MichaIng]

So the + is indicating that the file has an ACL indeed. Can you check this:

apt install acl
getfacl /mnt/nfs_client/dietpi-backup/data/etc/debian_version

EDIT: Ah, saw your edit now. I read a bit, and indeed ACLs on an NFSv4 share break cp -a, since it tries to preserve the ACL, but fails since NFSv4 inherently exposes them as its own ACL type to clients, incompatible with native POSIX ACL. Kinda annoying, but this means, even with server and client using Linux and ext4, the client cannot cp -a any file with ACL out of the NFS share, since the NFS server always translates them into its own format for transfer. rsync -a seems to be able to special-handle this, but also its -a option does not include ACLs.

I guess the ACLs in your case have no reasonable meaning on the DietPi system, so we could adjust the cp call to exclude them. Actually, it might not be a bad idea to generally include them for backup + restore, but if NFS servers apply ACLs to the backup by themselves, this might break things when restoring the backup, or grant users/groups unexpected permissions etc 🤔. Yeah, I guess we can add ACL support to dietpi-backup only when transferring/storing it as tarball, e.g. when someone finds time to add compression support. Until then, we can just remove -a when copying /etc/debian_version: it is not supposed to have any fancy permissions anyway, so root:root 0644 defaults are perfectly fine, and an updated mtime does not hurt either.

As workaround for you now: From the error prompt, select "Change command", and enter true or a single colon : to ignore the error. Even if you restore an older Debian version, the file data has been copied already, only the ACL could not be applied afterwards. The script still updates UUIDs if necessary and finishes the log, so there is still a little reason to not exit at this error.

[miloit]

I just edit the command and put it with out the option -a so than it was fine

Rest if the files restored perfectly so this is not an really necessary file

[MichaIng]

Solved for next release: https://github.com/MichaIng/DietPi/commit/7ea8be6