[SOLVED] All of a sudden, NFS sharing is busted. Getting 'mount(2) No such file or directory error

road hazard · 08-22-2020, 03:35 PM

When I was running Debian 10.3, this setup worked perfectly. After updating to 10.4 a few weeks ago, my NFS server has been busted. Been trying to fix it for a while and finally threw in the towel and decided to ask for help.

Here we go.....

/etc/exports from Server-PC: (server IP is 192.168.1.5)

Code:

/mnt/md0/data 192.168.1.1/24(ro,insecure,sync,all_squash,nohide,no_subtree_check,anonuid=1000,anongid=1000)

Server is up and running:

Code:

service nfs-kernel-server status
● nfs-server.service - NFS server and services
   Loaded: loaded (/lib/systemd/system/nfs-server.service; enabled; vendor preset: enabled)
   Active: active (exited) since Sat 2020-08-22 16:03:51 EDT; 14min ago
  Process: 20803 ExecStartPre=/bin/sleep 15 (code=exited, status=0/SUCCESS)
  Process: 20808 ExecStartPre=/usr/sbin/exportfs -r (code=exited, status=0/SUCCESS)
  Process: 20809 ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS (code=exited, status=0/SUCCESS)
 Main PID: 20809 (code=exited, status=0/SUCCESS)

Aug 22 16:03:36 server-pc systemd[1]: Starting NFS server and services...
Aug 22 16:03:51 server-pc systemd[1]: Started NFS server and services.

No restrictions in hosts.allow or hosts.deny

When doing exportfs:

Code:

sudo exportfs
/mnt/md0/data  	192.168.1.1/24

Code:

sudo cat /proc/fs/nfsd/versions
-2 +3 +4 +4.1 +4.2

And from the client (which has IP address 192.168.1.253)... fstab

Code:

192.168.1.5:/md0/data /mnt/data nfs ro,sync,hard,intr,noexec 0 0

Code:

sudo /sbin/showmount -e 192.168.1.5
Export list for 192.168.1.5:
/mnt/md0/data        192.168.1.1/24

But when trying to mount the NFS share:

Code:

sudo mount -a -vvvv
/                        : ignored
/media/cdrom0            : ignored
mount.nfs: timeout set for Sat Aug 22 16:24:38 2020
mount.nfs: trying text-based options 'hard,intr,vers=4.2,addr=192.168.1.5,clientaddr=192.168.1.253'
mount.nfs: mount(2): No such file or directory
mount.nfs: trying text-based options 'hard,intr,addr=192.168.1.5'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 192.168.1.5 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 192.168.1.5 prog 100005 vers 3 prot UDP port 36049
mount.nfs: mount(2): Permission denied
mount.nfs: access denied by server while mounting 192.168.1.5:/md0/data

Guessing something changed with some Debian update recently and this is what broke it since the NFS setup was humming along perfectly for several months until recently.

No firewall or security software installed on either machine. Absolutely nothing has changed except for Debian updates being applied once every few weeks.

berndbausch · 08-22-2020, 05:33 PM

Wouldn't you have to put /mnt/md0/data into fstab? "no such file or directory" probably means that /md0/data doesn't exist on the server.

road hazard · 08-22-2020, 09:01 PM

Quote:

Originally Posted by berndbausch

Wouldn't you have to put /mnt/md0/data into fstab? "no such file or directory" probably means that /md0/data doesn't exist on the server.

You're exactly right, that's what the problem was!! But, I'm 99.99999999999999% positive this was all working until just recently. That /data directory holds some movies I would access via Kodi. I know for a fact I used Kodi to access that folder about a month or so ago with no issues. I tried it a few weeks ago and it wasn't working so off to troubleshooting world I went. I'm at a total loss to explain what could have changed that fstab entry.

But in any case, using /mnt/md0/data vs. /md0/data fixed it, thanks for helping out!

berndbausch · 08-22-2020, 09:08 PM

I faintly remember the notion of an NFS root on the server, all shares being relative to that root. The client would then not mount the full pathnames of those shares, but the paths relative to that root.

This can be configured in /etc/exports. I am purely guessing now: Perhaps you used to configure it and the configuration was lost during the upgrade, possibly due to an over-eager post-install script.