What do you think this means?
“Make sure that the NFS share at the server is located on a filesystem with native symlink and UNIX permissions support”
Should I install something more/different on ubuntu?
this we usually already checked https://dietpi.com/forum/t/solved-backup-in-another-pc-in-the-same-network/6189/76
At least it should be supported by your Ubuntu system, as your main system is running on ext4
You did run touch /mnt/nfs_client/test as root user? Likely already checked but again:
ls -dl /mnt/nfs_client
If those do not show R/O mode, then I’m also out of idea why the server denies access out of nowhere. I can only suggest to set it up exactly like we do on DietPi (Debian and Ubuntu is exactly the same regarding such setups) and change the export to be:
/mnt/dietpibkp 192.168.1.15(rw,async,no_root_squash,fsid=0,crossmnt,no_subtree_check)
Then I think on the client (fstab) the path must be omitted (as fsid=0 makes /mnt/dietpibkp the root):
192.168.1.96:/ /mnt/nfs_client nfs nofail,noauto,x-systemd.automount
After the change:
unmount /mnt/nfs_client
mount /mnt/nfs_client
If i give this command ls -dl /mnt/nfs_clienton dietpi this is the output:
root@DietPi:~# ls -dl /mnt/nfs_client
drwxr-xr-x 2 root root 4096 Jan 29 12:35 /mnt/nfs_client
Honestly i still don’t understand if this is correct…
What do you think if I disinstall and then re-install the NFS server on ubuntu and try again all the steps? Maybe i did some mistakes before…
No, this looks fine.
root has write permissions, so from that end sudo touch /mnt/nfs_client/test should succeed. If not, please try it with the configuration changes I suggested. Else yes, at least worth a try to reinstall the NFS server. Ah also check logs on the Ubuntu systems, probably they give a hint when writes are denied by the server.
This is the result:
root@DietPi:~# sudo touch /mnt/nfs_client/test
touch: cannot touch '/mnt/nfs_client/test': Permission denied
root@DietPi:~#
This means I have no permissions, I gues 
Now, if I understood well now I should go back to Ubuntu and try to check if the export file is configured in this way:
/mnt/dietpibkp 192.168.1.15(rw,async,no_root_squash,fsid=0,crossmnt,no_subtree_check)
is this ok?
This is how the export on ubuntu appear:
# /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,async,no_root_squash,fsid=0,crossmnt,no_subtree_check)
#
Looks like it has saved correctly the file. Isn’t it?
Then I do not understand what to do more with
Then I think on the client (fstab) the path must be omitted (as fsid=0 makes /mnt/dietpibkp the root):
CODE: SELECT ALL192.168.1.96:/ /mnt/nfs_client nfs nofail,noauto,x-systemd.automount
After the change:
CODE: SELECT ALLunmount /mnt/nfs_client
mount /mnt/nfs_client
Should I work on dietpi, with this?
Now, in the /etc/fstab of your DietPi system, try to replace the NFS mount entry with:
192.168.1.96:/ /mnt/nfs_client nfs nofail,noauto,x-systemd.automount
and remount:
umount /mnt/nfs_client
mount /mnt/nfs_client
The one you have should be similar, but contains the /mnt/dietpibkp path, which should not be correct anymore now, with fsid=0 present on the server.
I followed those steps and now something has changed.
When I Launched again sudo touch /mnt/nfs_client/test
it gives me this output:
root@DietPi:~# sudo touch /mnt/nfs_client/test
touch: cannot touch '/mnt/nfs_client/test': Read-only file system
root@DietPi:~#
if I remember well before it gives me Permission denied.
Are we closer to the solution?
I’m sorry guys but at the moment I have a bigger problem: I’ve just changed the internet provider and with the new router I can’t reach dietpi any longer… I can reach all the devices I have in the network, but not the dietpi. Do you have any suggestions?
it has a static IP (but also ubuntu has it). The new router, instead of the old one has 192.168.0.1. The IP address is 192.168.1.15.
Should I try with a connected screen?
Basically you have 2 options. Connect a screen and keyboard to be able to change IP address of your DietPi system manually. Or change IP range of your router from 192.168.0.x into 192.168.1.x. But this would require to restart other network device to get the new IP range details.
Yes, with a changed network range 192.168.1.x => 192.168.0.x the Pi has no ability anymore to contact the router. In such cases, before switching the router, it is good to switch to DHCP, allow the router to apply a valid IP and gateway, then switch back to static based on new IP and gateway. Now, yes attach a screen and adjust it manually.
I attached a screen and I’ve noticed three tings:
- the dietpi does not start automatically (I should enter user and password), and before it logged in alone
- it says to me there is no ethernet connection because it can’t find the ethernet hardware. Before the router change, I was connecting only with ethernet
- the static IP was unable. I had to enable it and re-enter 192.168.1.15, because meanwhile, I’ve anyway changed the range in the router.
The problem now is that I can’t connect to the network.
Could be possible the router change had modified some dietpi configurations?
pls remember that I’ve also installed pi-hole in order to manage the DDNS in the network
pls remember that I’ve also installed pi-hole in order to manage the DDNS in the network
With your new router this might not be needed anymore as the new router handle this in a better way?
- the dietpi does not start automatically (I should enter user and password), and before it logged in alone
could you check the actually value on dietpi-autostart
Could be possible the router change had modified some dietpi configurations?
usually this should not have any effect to your device.
Did you checked LAN cable?
Are you able to change it?
Do you have LED active on your RPi while the cable is connected?
Is the RPI connected directly to your Router?
What the the Ethernet status in dietpi-config?
ok, after a “brutal” reboot and some cable changes I’m finally able to connect again through ssh to the dietpi…
I’ll check the previous discussion about how and if use the pi-hole now.
back to the topic, if I launch sudo touch /mnt/nfs_client/test
now the output is touch: cannot touch ‘/mnt/nfs_client/test’: No such device.
I guess because the network settings are changed also on ubuntu.
The new IP, looking in the pihole DHCP configurations, should be 192.168.1.112
Should I do something there?
you need to change the mount point on /etc/fstab
I changed the mounting point in this way:
192.168.1.112:/ /mnt/nfs_client nfs nofail,noauto,x-systemd.automount
Is this correct?
I try again with: sudo touch /mnt/nfs_client/test
But the result is still the same: touch: cannot touch ‘/mnt/nfs_client/test’: No such device
I notice that after the re-configuration of the new router (with all the port forwarding, IP ranges etc. etc.), the ubuntu system is not reachable from anydesk but I can see it in the “active DHCP leases” section in pi-hole, with 192.168.1.112 IP… is this strange, isn’t it?
So now pihole handles your DHCP and not the router (192.168.0.1) anymore??
This feels like a never ending story 
you could also have a look unter tools → network at you pihole admin panel to find out the IP
AnyDesk has nothing to do with DHCP. These are 2 different tools. If you use PiHole as DHCP server, it’s quite normal to see Ubuntu as active lease. I guess this was the initial idea of your setup to use PiHole as DHCP and not the router. Because your old Vodafon router was not supporting to set specific DNS server and had issues with your DDNS. But yeah not really related to the NFS issue. More some surrounding challenges. 
Yes, this is my initial idea to use pihole as DHCP, since also the new router does not support it. So I didn’t changed this configuration.
Now I’m exactly in the same situation I was when I started this thread… but with one more problem: I have to manage the ubuntu terminal, without being able to connect with it.