Is it normal that the backup is still running after 2 hours and a half?
Still running all the rsync: [receiver] chown “/mnt/nfs_client/…” failed: Operation not permitted (1) rows…
sometimes it shows a percentage… now it’s around 99%
execution time depends on target server speed. Anyway I guess the backup will not be correct as it is not able to set correct owner
I have no idea what went wrong.
I will try to get your current state of your config.
On your Ubuntu machine, make
ls -la /mnt/dietpibkp
and
cat /etc/exports
and
df -h
and show us the output pls.
On your Dietpi make
ls -la /mnt/nfs_client
and
df -h
and
cat /etc/fstab
and show us the output pls.
This is the Ubuntu output:
ls -la /mnt/dietpibkp
totale 7456
drwxrwxrwx 4 nobody nogroup 4096 gen 27 21:14 .
drwxr-xr-x 3 root root 4096 gen 18 08:50 ..
drwxr-xr-x 11 nobody nogroup 4096 gen 28 00:00 data
-rw-r--r-- 1 nobody nogroup 0 gen 26 19:36 demo.file
drwxr-xr-x 4 nobody nogroup 4096 gen 27 18:00 dietpi-backup
-rw-r--r-- 1 nobody nogroup 7613185 gen 28 00:00 dietpi-backup.log
ghezzia@NASCasaGhezzi:~$ cat /etc/exports
# /etc/exports: the access control list for filesystems which may be exported
# to NFS clients. See exports(5).
#
# Example for NFSv2 and NFSv3:
# /srv/homes hostname1(rw,sync,no_subtree_check) hostname2(ro,sync,no_subtree_check)
#
# Example for NFSv4:
# /srv/nfs4 gss/krb5i(rw,sync,fsid=0,crossmnt,no_subtree_check)
# /srv/nfs4/homes gss/krb5i(rw,sync,no_subtree_check)
/mnt/dietpibkp 192.168.1.15(rw,sync,no_root_squash,no_subtree_check)
#
ghezzia@NASCasaGhezzi:~$ df -h
File system Dim. Usati Dispon. Uso% Montato su
udev 3,8G 0 3,8G 0% /dev
tmpfs 775M 1,8M 774M 1% /run
/dev/sda2 457G 240G 195G 56% /
tmpfs 3,8G 640K 3,8G 1% /dev/shm
tmpfs 5,0M 4,0K 5,0M 1% /run/lock
tmpfs 3,8G 0 3,8G 0% /sys/fs/cgroup
/dev/loop4 128K 128K 0 100% /snap/bare/5
/dev/loop3 56M 56M 0 100% /snap/core18/2284
/dev/loop8 56M 56M 0 100% /snap/core18/2253
/dev/loop5 9,5M 9,5M 0 100% /snap/htop/3354
/dev/loop10 62M 62M 0 100% /snap/core20/1270
/dev/loop6 66M 66M 0 100% /snap/gtk-common-themes/1519
/dev/loop11 248M 248M 0 100% /snap/gnome-3-38-2004/87
/dev/loop7 219M 219M 0 100% /snap/gnome-3-34-1804/77
/dev/loop2 219M 219M 0 100% /snap/gnome-3-34-1804/72
/dev/loop12 51M 51M 0 100% /snap/snap-store/547
/dev/loop9 44M 44M 0 100% /snap/snapd/14295
/dev/loop0 66M 66M 0 100% /snap/gtk-common-themes/1515
/dev/loop14 55M 55M 0 100% /snap/snap-store/558
/dev/sda1 511M 5,3M 506M 2% /boot/efi
tmpfs 775M 56K 775M 1% /run/user/1000
/dev/loop15 44M 44M 0 100% /snap/snapd/14549
/dev/loop13 62M 62M 0 100% /snap/core20/1328
and this is the DietPi output:
root@DietPi:~# ls -la /mnt/nfs_client
total 7456
drwxrwxrwx 4 nobody nogroup 4096 Jan 27 21:14 .
drwxr-xr-x 9 root root 4096 Jan 22 15:58 ..
drwxr-xr-x 11 nobody nogroup 4096 Jan 28 00:00 data
-rw-r--r-- 1 nobody nogroup 0 Jan 26 19:36 demo.file
drwxr-xr-x 4 nobody nogroup 4096 Jan 27 18:00 dietpi-backup
-rw-r--r-- 1 nobody nogroup 7613185 Jan 28 00:00 dietpi-backup.log
root@DietPi:~# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 7.4G 3.4G 3.7G 49% /
devtmpfs 87M 0 87M 0% /dev
tmpfs 215M 3.5M 212M 2% /dev/shm
tmpfs 86M 11M 76M 13% /run
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 1.0G 0 1.0G 0% /tmp
tmpfs 50M 12K 50M 1% /var/log
/dev/mmcblk0p1 127M 52M 75M 42% /boot
/dev/sda1 916G 3.7G 913G 1% /mnt/ownclouddrive
192.168.1.96:/mnt/dietpibkp 457G 240G 195G 56% /mnt/nfs_client
/dev/sdb1 7.3G 3.6G 3.7G 49% /mnt/backup
root@DietPi:~# cat /etc/fstab
# You can use "dietpi-drive_manager" to setup mounts.
# NB: It overwrites and re-creates physical drive mount entries on use.
#----------------------------------------------------------------
# NETWORK
#----------------------------------------------------------------
192.168.1.96:/mnt/dietpibkp /mnt/nfs_client nfs nofail,noauto,x-systemd.automount
#----------------------------------------------------------------
# TMPFS
#----------------------------------------------------------------
tmpfs /tmp tmpfs size=1024M,noatime,lazytime,nodev,nosuid,mode=1777
tmpfs /var/log tmpfs size=50M,noatime,lazytime,nodev,nosuid,mode=1777
#----------------------------------------------------------------
# MISC: ecryptfs, vboxsf (VirtualBox shared folder), gluster, bind mounts
#----------------------------------------------------------------
#----------------------------------------------------------------
# SWAP SPACE
#----------------------------------------------------------------
/var/swap none swap sw
#----------------------------------------------------------------
# PHYSICAL DRIVES
#----------------------------------------------------------------
PARTUUID=0e2887fb-02 / ext4 noatime,lazytime,rw 0 1
PARTUUID=0e2887fb-01 /boot vfat noatime,lazytime,rw 0 2
UUID=614fbf4d-1260-405f-9f30-07d9c13067ce /mnt/ownclouddrive ext4 noatime,lazytime,rw,nofail,noauto,x-systemd.automount
UUID=2966eeaa-38a0-4cef-9469-fcd591d85249 /mnt/backup ext4 noatime,lazytime,rw,nofail,noauto,x-systemd.automount
I’m still guessing the issue is with the exported directory /mnt/dietpibkp as it belongs to nobody:nogroup. Maybe it would be an idea to clean the entire directory, change owner to root:root and try again.
ok, how can I clean the directory?
Do you mean on Ubuntu or Dietpi?
sudo rm -R /mnt/dietpibkp && sudo mkdir /mnt/dietpibkp && sudo chown root:root /mnt/dietpibkp
this directory only exists on your Ubuntu machine
Just some extra, not strictly necessary info:
I can’t confirm this after some more testing (Ok to be fair, I’m not testing with Ubuntu as host, but another Debian-based distro)
It worked for me with:
- nobody:nogroup @ /mnt/dietpibkp and the no_root_squash option in /etc/exports
- root:root @ /mnt/dietpibkp and the no_root_squash option in /etc/exports
Doesn’t worked with:
- nobody:nogroup @ /mnt/dietpibkp and WITHOUT no_root_squash option in /etc/exports
backup starts, but with same error as ghezzia when trying to run backup, respectively other errors when trying to choose the directory in dietpi-backup
- with root:root and WITHOUT no_root_squash option I get " Error creating test file /mnt/nfs_client/dietpi-backup/.test, unable to │
│ check filesystem permissions "
I’m excited what will happen at ghezzia’s machine
I followed the suggestion (on Ubuntu) but now a really strange thing happens.
I’m not sure this is related to the above command but, when I try to launch on dietpi the command dietpi-backup doesn’t show anything. I have to close and re-open the ssh connection to go back to the main menu…
the NFS mount is still working on your DietPi device?
reboot
cd /mnt/nfs_client
df -h
Here the output
root@DietPi:/mnt/nfs_client# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 7.4G 3.4G 3.7G 49% /
devtmpfs 87M 0 87M 0% /dev
tmpfs 215M 3.6M 212M 2% /dev/shm
tmpfs 86M 2.9M 84M 4% /run
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 1.0G 0 1.0G 0% /tmp
tmpfs 50M 24K 50M 1% /var/log
/dev/mmcblk0p1 127M 52M 75M 42% /boot
/dev/sda1 916G 3.7G 913G 1% /mnt/ownclouddrive
192.168.1.96:/mnt/dietpibkp 457G 236G 199G 55% /mnt/nfs_client
Looks like it is working, isn’t it?
Anyway, I tried to launch the backup panel and it is working now 
Can I try to backup again on Ubuntu? Or should I do something different before?
Just do a backup
nothing again. But now ti shows me this on a grey background:
Error creating test file /mnt/nfs_client/.test, unable to check filesystem │
│ permissions
and when I give OK
it shows me (still on a grey background):
Unsupported NFS share: │
│ │
│ /mnt/nfs_client is an NFS share which does not support UNIX permissions. │
│ │
│ Make sure that the NFS share at the server is located on a filesystem with │
│ native symlink and UNIX permissions support.
I got this exact same error when I didn’t set the “no_root_squash” option, but you didn’t change anything in your config?
What do you mean Jappe, change something on the server-side or client-side? On the Server-side I made a lot of configuration changes…
on server side
cat /etc/exports
What file system you are using on your Ubuntu device?
lsblk -o name,fstype,label,size,ro,type,mountpoint,partuuid,uuid
I hope this is what you meant.
cat /etc/exports
# /etc/exports: the access control list for filesystems which may be exported
# to NFS clients. See exports(5).
#
# Example for NFSv2 and NFSv3:
# /srv/homes hostname1(rw,sync,no_subtree_check) hostname2(ro,sync,no_subtree_check)
#
# Example for NFSv4:
# /srv/nfs4 gss/krb5i(rw,sync,fsid=0,crossmnt,no_subtree_check)
# /srv/nfs4/homes gss/krb5i(rw,sync,no_subtree_check)
/mnt/dietpibkp 192.168.1.15(rw,sync,no_root_squash,no_subtree_check)
#
ghezzia@NASCasaGhezzi:~$ lsblk -o name,fstype,label,size,ro,type,mountpoint,partuuid,uuid
NAME FSTYPE LABEL SIZE RO TYPE MOUNTPOINT PARTUUID UUID
loop0
squash 65,1M 1 loop /snap/gtk-
loop2
squash 219M 1 loop /snap/gnom
loop3
squash 55,5M 1 loop /snap/core
loop4
squash 4K 1 loop /snap/bare
loop5
squash 9,5M 1 loop /snap/htop
loop6
squash 65,2M 1 loop /snap/gtk-
loop7
squash 219M 1 loop /snap/gnom
loop8
squash 55,5M 1 loop /snap/core
loop9
squash 43,3M 1 loop /snap/snap
loop10
squash 61,9M 1 loop /snap/core
loop11
squash 247,9M 1 loop /snap/gnom
loop12
squash 51M 1 loop /snap/snap
loop13
squash 61,9M 1 loop /snap/core
loop14
squash 54,2M 1 loop /snap/snap
loop15
squash 43,4M 1 loop /snap/snap
sda 465,8G 0 disk
├─sda1
│ vfat 512M 0 part /boot/efi dfc4bd90-7e16-4c68-959e-388224edab66 1C52-C2E5
└─sda2
ext4 465,3G 0 part / 00e960eb-6cb6-4920-b32c-22088102bf63 6dec19b1-fc8f-47a3-ba03-480aa448f543
Is this comprehensible for you?
It wasn’t able to check whether UNIX permissions and symlinks are supported on NFS server-side because it failed to create the test file. There is no way to check the filesystem type directly via NFS, hence a test file is created, its owner changed and checked whether this was successful. So its still an issue with write permissions 
.
Before you start the backup for testing, always try whether you can create a file manually. If this fails, the backup attempt is unnecessary overhead :
touch /mnt/nfs_client/test
creating the file was not an issue on past. It was changing ownership always. But yeah still issues with permissons on server side.
If I try with touch /mnt/nfs_client/test
and this is the output:
touch: cannot touch '/mnt/nfs_client/test': Permission denied
definitely a permission issue…