Can't move userdata to btrfs drive with nfs

Creating a bug report/issue

I am trying to move the userdata directory on one raspberrypi cm4 node (node 1 - nfs_client) to another with a raid1 btrfs drive ( node 2 - nfs server). Been at it for 2 days now. The nfs client / server is setup correctly. I can create and post files on /mnt/nfs_client on node 1 and it shows up on the btrfs server. So I assume there are no permission isuses etc.

The only thing I can’t do is to move the /mnt/dietpi_userdata directory on node 1 to node 2. I get the error message:

User data transfer: Failed                                                                                           │
                     │                                                                                                                      │
                     │ [FAILED] Filesystem type nfs4 of /mnt/nfs_client/dietpi_userdata is not supported for transferring DietPi user data. │
                     │ Transfer aborted.                                                                                                    │
                     │  - The filesystem type must be ext2/3/4, F2FS, Btrfs, XFS or ZFS for native symlink and UNIX permissions             │
                     │ compatibilities.                                                                                                     │
                     │                                                                                                                      │
                     │ No changes have been applied.

Required Information

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


  • Distro version | echo $G_DISTRO_NAME $G_RASPBIAN
    bullseye 0

  • Kernel version | uname -a
    Linux cm4-1 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux

  • Architecture | dpkg --print-architecture

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

Here is what fstab on node 2 ( nfs seever) looks like:

# You can use "dietpi-drive_manager" to setup mounts.
# NB: It overwrites and re-creates physical drive mount entries on use.

tmpfs /tmp tmpfs size=3931M,noatime,lazytime,nodev,nosuid,mode=1777
tmpfs /var/log tmpfs size=50M,noatime,lazytime,nodev,nosuid

# MISC: ecryptfs, vboxsf, glusterfs, mergerfs, bind, Btrfs subvolume
UUID=cf6db72f-9d66-4b81-b479-e331421605c2 /mnt/storage/cm41/dietpi_userdata btrfs defaults,ssd,relatime,lazytime,discard=async,space_cache,compress=zstd,subvol=/@cm41_dietpi_userdata,nofail,x-systemd.device-timeout=20 0 0


PARTUUID=a0998a78-02 / ext4 noatime,lazytime,rw 0 1
PARTUUID=a0998a78-01 /boot vfat noatime,lazytime,rw 0 2
UUID=cf6db72f-9d66-4b81-b479-e331421605c2 /mnt/storage btrfs noatime,lazytime,rw,nofail,noauto,x-systemd.automount

As stated on the error message. We don’t support to relocate user data on a network share. It should be a local drive. If you like do something like this, it would need to be carried out manually without our tools/script.

1 Like

use rsync…

If you already have the external device mounted, just use rsync to copy over the data

This is the command I use to “backup” my audiobookshelf server from my main UNRAID server to a smaller backup terramaster server with ZFS

rsync -avzhP --delete /audiobooks/* root@
Of course I use the “delete” flag because on my main server I get audiobooks in .mp3 format and use audiobookshelf to covert/compress/compile them into a single .m4b at 64k {of which I no longer need the buckets of individual .mp3 files anymore)
I also have to enter the password in the command after (I guess I could use a credentials file and automate it)

It is not an external drive. It is an NFS network share. And our scripts don’t support that for a reason. If DietPi user data is on an NFS share, there may be problems with the system start-up. Some services might start before the NFS share is available, causing the service start to fail. In this case, the dependencies would have to be checked manually and the corresponding services configured to start only when the NFS shar is available. Therefore, our scripts only support local disks.

However, if you really want to, you can configure everything manually.