DietPi-Drive_Manager | NFS mounting issue

Created on 5 Jul 2018  ·  45Comments  ·  Source: MichaIng/DietPi

Creating a bug report/issue:

Reference: https://dietpi.com/phpbb/viewtopic.php?f=9&t=4169&start=10#p13378

Required Information:

  • DietPi version | 6.10
  • Distro version | Stretch
  • SBC device | RPi2

Additional Information (if applicable):

  • Software title | NFS mount

Expected behaviour:

  • NFS drive should mount

Actual behaviour:

root@DietPi:~# mount -t nfs4 -o port=2049 192.168.0.11:/volume1/video /mnt/nfs
mount.nfs4: Protocol not supported
...
root@DietPi:~# mount -t nfs -o port=2049 192.168.0.11:/volume1/video /mnt/nfs
mount.nfs: Protocol not supported

Extra details:

  • Problem got solved with enabling nfs4 support on NAS (Synology).
  • We by default add nfs4 to fstab.
  • Maybe there is a way to test first or by default add it a more compatible way?
  • Sorry can't add much more here, as I never worked with NFS 😉.
External Bug Solution available Via Forum
Source
picture MichaIng
👍1

Most helpful comment

Okay, nofail added to network drives as well. Only thing that is outstanding is:

  • NFSv3 needs the path to the export dir added to mount command and fstab entry.
  • NFSv4 needs just <IP>:/. If path is added, v4 connection attempts will fails and connection will be v3. If server is v4 only, then connection will completely fail.

Thus, currently dietpi-drive_manager cannot be used to add v3 drives directly (uses v4 method). To enable this we would need to identify, which version the server is, properly just via test mounting and catch failure, and in case ask user to verify v3 server enter path as well... Some testing, some good thoughts and ideas needed, thus moved to v6.13 😄.

I will close this issue, as initial problem is solved.

picture MichaIng on 20 Jul 2018
👍2 ❤1

All 45 comments

@Fourdee
Maybe we can as well spawn some hint on update, that network drive options have been moved from dietpi-config to dietpi-drive_manager 🙂.

MichaIng picture MichaIng on 5 Jul 2018

Maybe we can as well spawn some hint on update, that network drive options have been moved from dietpi-config to dietpi-drive_manager

Yep 👍

Sorry can't add much more here, as I never worked with NFS

Same here.

auto works, unsure if it changes anything, or has any effect.

192.168.0.113:/ /mnt/nfs auto auto,_netdev 0  0
Fourdee picture Fourdee on 5 Jul 2018

Hmm

nfsvers=n
The NFS protocol version number used to contact the server's NFS service. If the server does not support the requested version, the mount request fails. If this option is not specified, the client negotiates a suitable version with the server, trying version 4 first, version 3 second, and version 2 last.

https://linux.die.net/man/5/nfs

Fourdee picture Fourdee on 5 Jul 2018

@Fourdee
The fstype field contains "nfs". Use of the "nfs4" fstype in /etc/fstab is deprecated. So this we should change at least.

Also can't find _netdev option on Debian man page: https://manpages.debian.org/stretch/manpages-de/nfs.5.de.html

MichaIng picture MichaIng on 5 Jul 2018
👍1

@MichaIng

The fstype field contains "nfs". Use of the "nfs4" fstype in /etc/fstab is deprecated. So this we should change at least.

Done, passed testing.

Fourdee picture Fourdee on 5 Jul 2018
👍1

https://docs.oracle.com/cd/E19253-01/816-4555/rfsrefer-18/index.html

  • nfs 2/3 = mount -F nfs -r bee:/export/share/man /usr/man
  • nfs 4 = mount -F nfs -o vers=4 bee:/export/share/man /usr/man

Both options mount as NFS4:

mount -t nfs -o vers=4,port=2049 192.168.0.113:/ /mnt/nfs_client
root@DietPi:~# mount | grep nfs
192.168.0.113:/ on /mnt/nfs_client type nfs4 (rw,relatime,vers=4.0,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.0.32,local_lock=none,addr=192.168.0.113)

--

root@DietPi:~# umount /mnt/nfs_client
root@DietPi:~# mount -t nfs -o port=2049 192.168.0.113:/ /mnt/nfs_client
root@DietPi:~# mount | grep nfs
192.168.0.113:/ on /mnt/nfs_client type nfs4 (rw,relatime,vers=4.0,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.0.32,local_lock=none,addr=192.168.0.113)
Fourdee picture Fourdee on 6 Jul 2018

@MichaIng

Also can't find _netdev option on Debian man page: https://manpages.debian.org/stretch/manpages-de/nfs.5.de.html

http://man7.org/linux/man-pages/man8/mount.8.html

   _netdev
          The  filesystem  resides  on  a  device  that requires network
          access (used to prevent the system from  attempting  to  mount
          these  filesystems  until  the network has been enabled on the
          system).

Basically sets them to:

 systemctl status remote-fs.target
Fourdee picture Fourdee on 6 Jul 2018

@Fourdee
Jep, also found it on https://wiki.ubuntuusers.de/NFS/, totally reasonable 👍.

MichaIng picture MichaIng on 6 Jul 2018

@Fourdee
Just checked, what we made different with earlier versions. We added the fstab entry identically, just nfs4 type, but nfs however should solve more than break.

But we didn't mount the nfs drive explicitly, but just called mount -a maybe via fast it is mounted a bid different, then we do now? So users @mgherghi with the protocol error could just try mount -a and if this works, maybe there is some debug option to check how it is done based on fstab entry, so we can apply.

MichaIng picture MichaIng on 7 Jul 2018
👍1

@MichaIng

I'am hoping this user can assist us with testing, hopefully find a solution for NFSv3, then I can implement into drive_man, as per the Samba method.

Fourdee picture Fourdee on 7 Jul 2018

Notes:

NFS v3 server:
https://unix.stackexchange.com/q/205403/98891
RPCNFSDCOUNT="8 --no-nfs-version 4"
Unable to mount with all possible options...

Fourdee picture Fourdee on 7 Jul 2018

I'm seeing the same thing since upgrading to 6.11 per my post here.

https://dietpi.com/phpbb/viewtopic.php?f=9&t=4169&start=10#p13427

Happy to provide more details or test fixes.

duncansimpson picture duncansimpson on 8 Jul 2018

@duncansimpson
Thanks for joining here. Good to here again, that it worked pre v6.10.

Trace again how we added NFS pre v6.10:

On the other hand I see you guys often have sub paths for NFS server within fstab entry, e.g. 192.168.1.10:/mnt/user/music_test

  • This can't have been added via dietpi-config, as our script handled and added IP only since long time ago. But might this be an issue as well, that some NFS servers just handle access to those sub directories correctly, otherwise refuse connection with no-protocol-support error?
  • This would mean we need to allow adding NFS servers with IP and sub path as above.

Other explanation: APT update of nfs-common broke v3 support

    Commit 71b807e1 introduce a regression that
    caused v3 not to be tried when v4 was not
    supported by the server during auto negation.
MichaIng picture MichaIng on 8 Jul 2018
❤1 👍1

So what should i do ?

mgherghi picture mgherghi on 9 Jul 2018

@MichaIng

WRT the subpaths and fstab entries, yes I need to use subpaths in this case, because I have a range of nfs shares on the remote server and I don't need/want all of them visible on my Pi. I added these entries many months ago, and they have been working fine through numerous upgrades of DietPi until I upgraded from 6.9 to 6.11. No other changes were made during the most recent upgrade, so I can only suggest that it appears to be related to the APT update of nfs-common.

duncansimpson picture duncansimpson on 9 Jul 2018

@duncansimpson
Not sure, but I think on update the fstab file got recreated, as well as the network drive entries. So the path got removed. Please try to manually re-add it within fstab and mount -a.

So we need to allow adding paths for the target server on v6.12, perhaps via separate input field or included within IP input field.

MichaIng picture MichaIng on 9 Jul 2018

@MichaIng

I don't know if the fstab got recreated on upgrade, I didn't check the timestamp on it, however straight after the upgrade I noticed that my remote shares weren't connected. So I checked fstab and saw my entries _were still there_, intact with the sub paths still there also, so I know the update did not remove the entries and did not remove the subpaths.

mount -a doesn't remount the shares. It also gives the mount.nfs: Protocol not supported message for each share (I have 4 in total).

FWIW I also have a mount to a usb local hardrive that I added to fstab which stayed in place after the update and works fine.

I later tried the new dietpi-drive_manager, which also fails with the same mount.nfs: Protocol not supported. I noticed using that utility _did_ recreate my fstab however. When it did that, it reordered all the entries, changed the comments. It left my nfs mount entries in tact with the subpaths, however it removed my local USB drive mount from fstab, so I had to re-add that entry manually.

I understand that manually editing fstab is not supported by you guys, and I'm ok with that, however the underlying nfs client seems to be broken since either 6.10 or 6.11. I'll see if I can find an old SD card tonight and download 6.9 to confirm those entries still work in my specific scenario.

Let me know if there anything else you'd like me to check or test.

duncansimpson picture duncansimpson on 9 Jul 2018

@duncansimpson
Last I can think of: We removed net-tools from DietPi core dependencies. Nowadays it is/should be replaced everywhere by iproute2, but who knows if somehow old tools/methods use net-tools commands, especially as we talk about old NFS versions. Although we did not purge the package, just autoremoved in case it is no dependency of any other installed package, it is worth trying:

apt install net-tools
mount -a

If this also does not help, my only left idea, as above, is dropped support (actually not, current upstream version 2.3.2 still handles v2 and v3) or bug with latest nfs-common patch.
Which device you use?
If non-RPi, please download 1.3.4-2.1 from 2017 from here with correct arch: http://ftp.uk.debian.org/debian/pool/main/n/nfs-utils/
On RPi armhf should work fine as well, but would be better to check for older version on Raspbian repo then.

MichaIng picture MichaIng on 9 Jul 2018

Thanks @MichaIng

I'm at work at the moment (NZ Time), I'll try that tonight (about 8hrs from now).

FYI I'm using a RPi 3, however I also have an older 2B I can tinker with if necessary, just need to find a spare SD card somewhere.

duncansimpson picture duncansimpson on 10 Jul 2018

@MichaIng

I tried apt install net-tools, no improvement unfortunately:

root@DietPi:~# mount -a
mount.nfs: Protocol not supported
mount.nfs: Protocol not supported
mount.nfs: Protocol not supported
mount.nfs: Protocol not supported
root@DietPi:~# apt install net-tools
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
  net-tools
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 220 kB of archives.
After this operation, 818 kB of additional disk space will be used.
Get:1 http://mirror.reap.net.nz/raspbian/raspbian stretch/main armhf net-tools armhf 1.60+git20161116.90da8a0-1 [220 kB]
Fetched 220 kB in 1s (216 kB/s)
Selecting previously unselected package net-tools.
(Reading database ... 20705 files and directories currently installed.)
Preparing to unpack .../net-tools_1.60+git20161116.90da8a0-1_armhf.deb ...
Unpacking net-tools (1.60+git20161116.90da8a0-1) ...
Setting up net-tools (1.60+git20161116.90da8a0-1) ...
root@DietPi:~# mount -a
mount.nfs: Protocol not supported
mount.nfs: Protocol not supported
mount.nfs: Protocol not supported
mount.nfs: Protocol not supported
root@DietPi:~#

Note as mentioned earlier I have 4 nfs entries in fstab, hence 4 messages.

duncansimpson picture duncansimpson on 10 Jul 2018
👍1

@duncansimpson
Okay, so we can sort out net-tools 👍.

MichaIng picture MichaIng on 10 Jul 2018

@duncansimpson
Which machine/SBC do you use/faced the issue on?
Did you try to manually install/downgrade nfs-common package to an earlier version: http://ftp.uk.debian.org/debian/pool/main/n/nfs-utils/

Otherwise I am out of ideas, since I can't see anything any more that changed from v6.9 to v6.11:

  • net-tools sorted out
  • mount command tried with old and new and various alternative arguments
  • fstab entry tried with old and new and various different settings

Nothing helped so far to re-enable NFSv3 support.

@Fourdee
Do you have ideas what else to try?

MichaIng picture MichaIng on 17 Jul 2018

@MichaIng

The only thing I can suggest (if not already done), is for @duncansimpson and @mgherghi try mounting all the possible NFS v2/v3 modes, eg:

mount -t nfs -o vers=2,port=2049 192.168.0.11:/volume1/video /mnt/nfs
mount -t nfs -o vers=3,port=2049 192.168.0.11:/volume1/video /mnt/nfs

Failing that, i'am out of ideas. I have minimal real world NFS experience, only basic configuration and installation.

I did attempt to replicate a v2/v3 server for testing, but unsuccessful: https://github.com/Fourdee/DietPi/issues/1898#issuecomment-403225412. I'll try to give it another stab when time permits.

Fourdee picture Fourdee on 18 Jul 2018

root@DietPi:/mnt# mount -t nfs -o vers=2,port=2049 192.168.1.1:/Seagates /mnt/nfs
mount: wrong fs type, bad option, bad superblock on 192.168.1.1:/Seagates,
missing codepage or helper program, or other error
(for several filesystems (e.g. nfs, cifs) you might
need a /sbin/mount. helper program)

   In some cases useful info is found in syslog - try
   dmesg | tail or so.

root@DietPi:/mnt# mount -t nfs -o vers=3,port=2049 192.168.1.1:/Seagates /mnt/nfs
mount: wrong fs type, bad option, bad superblock on 192.168.1.1:/Seagates,
missing codepage or helper program, or other error
(for several filesystems (e.g. nfs, cifs) you might
need a /sbin/mount. helper program)

   In some cases useful info is found in syslog - try
   dmesg | tail or so.

root@DietPi:/mnt#

mgherghi picture mgherghi on 18 Jul 2018
👍1

Hi guys,

In my case this is all on a Pi 3.

Here's NFSv3 test

root@DietPi:~# mount -t nfs -o vers=3 -v 192.168.1.10:/mnt/user/music_test /mnt/test/
mount.nfs: timeout set for Wed Jul 18 19:01:34 2018
mount.nfs: trying text-based options 'vers=3,addr=192.168.1.10'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 192.168.1.10 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 192.168.1.10 prog 100005 vers 3 prot UDP port 33776
mount.nfs: Protocol not supported
root@DietPi:~#

And v2 test:

root@DietPi:~# mount -t nfs -o vers=2 -v 192.168.1.10:/mnt/user/music_test /mnt/test/
mount.nfs: timeout set for Wed Jul 18 19:04:34 2018
mount.nfs: trying text-based options 'vers=2,addr=192.168.1.10'
mount.nfs: prog 100003, trying vers=2, prot=6
mount.nfs: trying 192.168.1.10 prog 100003 vers 2 prot TCP port 2049
mount.nfs: portmap query retrying: RPC: Program/version mismatch
mount.nfs: prog 100003, trying vers=2, prot=17
mount.nfs: trying 192.168.1.10 prog 100003 vers 2 prot UDP port 2049
mount.nfs: portmap query failed: RPC: Program/version mismatch
mount.nfs: Protocol not supported
root@DietPi:~#

Is there a 6.9 image I can revert back to, in order to confirm that still works?

duncansimpson picture duncansimpson on 18 Jul 2018
👍1

WRT to the request earlier to rollback to the 2017 version of nfs-common which is 1.3.4-2.1. I can't because that is the version in place already.

root@DietPi:~# apt-cache policy nfs-common
nfs-common:
  Installed: 1:1.3.4-2.1
  Candidate: 1:1.3.4-2.1
  Version table:
 *** 1:1.3.4-2.1 500
        500 http://raspbian.raspberrypi.org/raspbian stretch/main armhf Packages
        100 /var/lib/dpkg/status
root@DietPi:~#

trying to install the 2018 version, 1.3.4-2.2 fails:

root@DietPi:~# apt-get install nfs-common=1:1.3.4-2.2
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Version '1:1.3.4-2.2' for 'nfs-common' was not found
root@DietPi:~#

And checking the current version by trying to install it again:

root@DietPi:~# apt-get install nfs-common=1:1.3.4-2.1
Reading package lists... Done
Building dependency tree
Reading state information... Done
nfs-common is already the newest version (1:1.3.4-2.1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
root@DietPi:~#

And apt-get update doesn't find it either

root@DietPi:~# apt-get -u --dry-run upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  ca-certificates dpkg file libmagic-mgc libmagic1 libsystemd0 libudev1 systemd systemd-sysv tzdata udev
11 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Inst dpkg [1.18.24] (1.18.25 Raspbian:stable [armhf])
Conf dpkg (1.18.25 Raspbian:stable [armhf])
Inst libsystemd0 [232-25+deb9u2] (232-25+deb9u4 Raspbian:stable [armhf]) [systemd:armhf ]
Conf libsystemd0 (232-25+deb9u4 Raspbian:stable [armhf]) [systemd:armhf ]
Inst systemd [232-25+deb9u2] (232-25+deb9u4 Raspbian:stable [armhf])
Inst udev [232-25+deb9u2] (232-25+deb9u4 Raspbian:stable [armhf]) []
Inst libudev1 [232-25+deb9u2] (232-25+deb9u4 Raspbian:stable [armhf])
Conf libudev1 (232-25+deb9u4 Raspbian:stable [armhf])
Conf systemd (232-25+deb9u4 Raspbian:stable [armhf])
Inst systemd-sysv [232-25+deb9u2] (232-25+deb9u4 Raspbian:stable [armhf])
Inst tzdata [2018c-0+deb9u1] (2018e-0+deb9u1 Raspbian:stable [all])
Inst file [1:5.30-1+deb9u1] (1:5.30-1+deb9u2 Raspbian:stable [armhf]) []
Inst libmagic1 [1:5.30-1+deb9u1] (1:5.30-1+deb9u2 Raspbian:stable [armhf]) []
Inst libmagic-mgc [1:5.30-1+deb9u1] (1:5.30-1+deb9u2 Raspbian:stable [armhf])
Inst ca-certificates [20161130+nmu1] (20161130+nmu1+deb9u1 Raspbian:stable [all])
Conf udev (232-25+deb9u4 Raspbian:stable [armhf])
Conf systemd-sysv (232-25+deb9u4 Raspbian:stable [armhf])
Conf tzdata (2018e-0+deb9u1 Raspbian:stable [all])
Conf file (1:5.30-1+deb9u2 Raspbian:stable [armhf])
Conf libmagic1 (1:5.30-1+deb9u2 Raspbian:stable [armhf])
Conf libmagic-mgc (1:5.30-1+deb9u2 Raspbian:stable [armhf])
Conf ca-certificates (20161130+nmu1+deb9u1 Raspbian:stable [all])
root@DietPi:~#
duncansimpson picture duncansimpson on 18 Jul 2018

@duncansimpson
Okay, Raspbian is one version behind then. The chance that this was the reason converged to zero anyway.

To test v6.9 handling please do the following:

cp -a /DietPi/dietpi/dietpi-drive_manager ~/
cp -a /etc/fstab ~/
wget https://raw.githubusercontent.com/Fourdee/DietPi/f7170dc0f125c83d9230daa9237076d92ab22d50/dietpi/dietpi-drive_manager -O /DietPi/dietpi/dietpi-drive_manager
wget https://raw.githubusercontent.com/Fourdee/DietPi/f7170dc0f125c83d9230daa9237076d92ab22d50/dietpi/func/dietpi-set_nfsclient -O /DietPi/dietpi/func/dietpi-set_nfsclient
chmod +x /DietPi/dietpi/dietpi-drive_manager /DietPi/dietpi/func/dietpi-set_nfsclient
/DietPi/dietpi/func/dietpi-set_nfsclient

Enter IP and in case adjust the /etc/fstab entry with the full path info.
That would recover at least fstab and nfs drive handling of v6.9.
To revert:

cp -a ~/dietpi-drive_manager /DietPi/dietpi/dietpi-drive_manager
cp -a ~/fstab /etc/fstab
rm /DietPi/dietpi/func/dietpi-set_nfsclient
rm /boot/dietpi/func/dietpi-set_nfsclient

To fully revert to v6.9, if you have no backup somewhere, would be to download and flash the current available RPi DietPi image: https://dietpi.com/downloads/images/DietPi_RPi-ARMv6-Stretch.7z
Backup current SD card or simply replace with another one for testing of course.

MichaIng picture MichaIng on 18 Jul 2018

To fully revert to v6.9, if you have no backup somewhere, would be to download and flash the current available RPi DietPi image: https://dietpi.com/downloads/images/DietPi_RPi-ARMv6-Stretch.7z
Backup current SD card or simply replace with another one for testing of course.

Thanks @MichaIng. I have a spare SD card so I'll try that tonight.

duncansimpson picture duncansimpson on 19 Jul 2018

@MichaIng

I dug out my spare SD card, put the 6.9 image on there, let it do its thing after first boot, completed the install, then installed nfs-client via dietpi-software and rebooted.

Results of nfs connection test were successful:

root@DietPi:~# apt-cache policy nfs-common
nfs-common:
  Installed: 1:1.3.4-2.1
  Candidate: 1:1.3.4-2.1
  Version table:
 *** 1:1.3.4-2.1 500
        500 http://raspbian.raspberrypi.org/raspbian stretch/main armhf Packages
        100 /var/lib/dpkg/status
root@DietPi:~# mount -t nfs -v 192.168.1.10:/mnt/user/music_test /mnt/test/
mount.nfs: timeout set for Thu Jul 19 09:08:00 2018
mount.nfs: trying text-based options 'vers=4.2,addr=192.168.1.10,clientaddr=192.168.1.21'
mount.nfs: mount(2): Invalid argument
mount.nfs: trying text-based options 'vers=4.1,addr=192.168.1.10,clientaddr=192.168.1.21'
mount.nfs: mount(2): Protocol not supported
mount.nfs: trying text-based options 'vers=4.0,addr=192.168.1.10,clientaddr=192.168.1.21'
mount.nfs: mount(2): Protocol not supported
mount.nfs: trying text-based options 'addr=192.168.1.10'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 192.168.1.10 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 192.168.1.10 prog 100005 vers 3 prot UDP port 33776
root@DietPi:~# ls -l /mnt/test
total 8
drwxrwxrwx 1 99 users   36 Jan  7  2017 2L
drwxrwxrwx 1 99 users 4096 Dec 11  2014 linn 24bits of xmas
drwxrwxrwx 1 99 users 4096 Dec 16  2013 Stereophile Test CD, Vol. 1
drwxrwxrwx 1 99 users   43 Aug  7  2017 Various Artists
root@DietPi:~#

Note this is the same version of nfs-common as was present on the 6.11 SD card.

Next I upgraded DietPi on the spare SD card from 6.9 to 6.11 and redid the NFS test. It now fails, despite the nfs-common package being the same version:

 ───────────────────────────────────────
 DietPi     | 09:45 | Thu 19/07/18
 ───────────────────────────────────────
 v6.11      | RPi B (armv6l)
 ───────────────────────────────────────
 eth0       | 192.168.1.21
 ───────────────────────────────────────
 DietPi Core Team   : Daniel Knight (founder), MichaIng, K-Plan
 Image creator      : DietPi Core Team
 Pre-image used     : Raspbian Lite
 Web                : https://DietPi.com | https://twitter.com/dietpi_
 Donate             : https://goo.gl/pzISt9
 DietPi web hosting : Powered by https://MyVirtualServer.com

 dietpi-launcher  = All the DietPi programs in one place.
 dietpi-config    = Feature rich configuration tool for your device.
 dietpi-software  = Select optimized software for installation.
 htop             = Resource monitor.
 cpu              = Shows CPU information and stats.

root@DietPi:~# apt-cache policy nfs-common
nfs-common:
  Installed: 1:1.3.4-2.1
  Candidate: 1:1.3.4-2.1
  Version table:
 *** 1:1.3.4-2.1 500
        500 http://raspbian.raspberrypi.org/raspbian stretch/main armhf Packages
        100 /var/lib/dpkg/status
root@DietPi:~# mount -t nfs -v 192.168.1.10:/mnt/user/music_test /mnt/test/
mount.nfs: timeout set for Thu Jul 19 09:48:10 2018
mount.nfs: trying text-based options 'vers=4.2,addr=192.168.1.10,clientaddr=192.168.1.21'
mount.nfs: mount(2): Invalid argument
mount.nfs: trying text-based options 'vers=4.1,addr=192.168.1.10,clientaddr=192.168.1.21'
mount.nfs: mount(2): Protocol not supported
mount.nfs: trying text-based options 'vers=4.0,addr=192.168.1.10,clientaddr=192.168.1.21'
mount.nfs: mount(2): Protocol not supported
mount.nfs: trying text-based options 'addr=192.168.1.10'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 192.168.1.10 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 192.168.1.10 prog 100005 vers 3 prot UDP port 33776
mount.nfs: Protocol not supported
root@DietPi:~#

So that confirms (for me at least) that something is different between 6.9 and 6.11 WRT NFS client connectivity, and yet it appears to be unrelated to the nfs-common package version at least.

duncansimpson picture duncansimpson on 19 Jul 2018
❤1 👍1

Note the tests I just did were on an old Pi Model B connected to the same switch as the Pi3, so I think that also rules out hardware fault or network issues.

duncansimpson picture duncansimpson on 19 Jul 2018
👍1

@duncansimpson
Great test.

That also proves, that it is totally outside of dietpi-drive_manager or the way we attempt(ed) mounting. So no need to check in this direction. Nice also to see how mount.nfs itself tries all versions from 4.2 down to 3, UDP and TCP.

How did you prevent the automated dietpi-update on first boot? Was there some APT upgrade done before you tested it on 6.9, or better were there some packages upgraded on dietpi-update to v6.11? This had no effect on nfs-common, as current version (on Raspbian) is dated back a while, but maybe some other involved package upgrade might be the reason?

I will now set up an NFSv3 server myself and play around: https://unix.stackexchange.com/questions/205403/disable-nfsv4-server-on-debian-allow-nfsv3
Unbelievable that the reason is so hard to find here 🤔 😓, and what a chance that it appeared the same version jump where er reworked drive_manager and NFS mount method, and still it is not related to that. At least this made me investigating into the wrong direction for quite a while...

Fourdee already moved this issue to v6.13 milestone. I will give my test today to identify the reason, but as we want to release v6.12 today (due to some serious cron issue), the chance is low that this will be included. However as always, manual fix would be possible 😉.

MichaIng picture MichaIng on 19 Jul 2018

Took a while until I found netbase to be needed for NFS server to work. On Jessie this is not installed as dependency of nfs-kernel-server, as on Stretch+.
Taking into account the config bug within the link above, I have now a NFSv3 only server on a Jessie VM and could replicate the connection issue from another Stretch VM.

Installing netbase as well on the NFS client side, the connection fails differently:

root@VM-Stretch:~# mount -t nfs -v 192.168.178.28:/ /mnt/VM-Jessie
mount.nfs: timeout set for Thu Jul 19 13:38:58 2018
mount.nfs: trying text-based options 'vers=4.2,addr=192.168.178.28,clientaddr=192.168.178.29'
mount.nfs: mount(2): Protocol not supported
mount.nfs: trying text-based options 'vers=4.1,addr=192.168.178.28,clientaddr=192.168.178.29'
mount.nfs: mount(2): Protocol not supported
mount.nfs: trying text-based options 'vers=4.0,addr=192.168.178.28,clientaddr=192.168.178.29'
mount.nfs: mount(2): Protocol not supported
mount.nfs: trying text-based options 'addr=192.168.178.28'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 192.168.178.28 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 192.168.178.28 prog 100005 vers 3 prot UDP port 46199
mount.nfs: mount(2): Permission denied
mount.nfs: access denied by server while mounting 192.168.178.28:/
  • With NFSv4 enabled, no permission issues. Further investigating.

€: Ah now it works. On NFSv4, no path needs to be given, on NFSv3 the path needs to be given:

root@VM-Stretch:~# mount -t nfs -v 192.168.178.28:/mnt/dietpi_userdata /mnt/VM-Jessie
mount.nfs: timeout set for Thu Jul 19 14:06:45 2018
mount.nfs: trying text-based options 'vers=4.2,addr=192.168.178.28,clientaddr=192.168.178.29'
mount.nfs: mount(2): Protocol not supported
mount.nfs: trying text-based options 'vers=4.1,addr=192.168.178.28,clientaddr=192.168.178.29'
mount.nfs: mount(2): Protocol not supported
mount.nfs: trying text-based options 'vers=4.0,addr=192.168.178.28,clientaddr=192.168.178.29'
mount.nfs: mount(2): Protocol not supported
mount.nfs: trying text-based options 'addr=192.168.178.28'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 192.168.178.28 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 192.168.178.28 prog 100005 vers 3 prot UDP port 46199
root@VM-Stretch:~# df
Filesystem                          1K-blocks   Used Available Use% Mounted on
udev                                  1021784      0   1021784   0% /dev
tmpfs                                  205244   4348    200896   3% /run
/dev/sda1                             8189368 660344   7093312   9% /
tmpfs                                 1026204      0   1026204   0% /dev/shm
tmpfs                                    5120      0      5120   0% /run/lock
tmpfs                                 1026204      0   1026204   0% /sys/fs/cgroup
tmpfs                                   51200     12     51188   1% /var/log
tmpfs                                 1026204      0   1026204   0% /tmp
tmpfs                                   10240   1480      8760  15% /DietPi
192.168.178.28:/mnt/dietpi_userdata   8123904 799744   6888448  11% /mnt/VM-Jessie

@duncansimpson @Fourdee
Could you try as well apt install netbase?
And then add the path as well to mount command.

To check NFS versions server side: cat /proc/fs/nfsd/versions

For the record, with NFSv4:

root@VM-Stretch:/mnt# mount -t nfs -v 192.168.178.28:/ /mnt/VM-Jessie
mount.nfs: timeout set for Thu Jul 19 14:12:13 2018
mount.nfs: trying text-based options 'vers=4.2,addr=192.168.178.28,clientaddr=192.168.178.29'
mount.nfs: mount(2): Protocol not supported
mount.nfs: trying text-based options 'vers=4.1,addr=192.168.178.28,clientaddr=192.168.178.29'
root@VM-Stretch:/mnt# df
Filesystem       1K-blocks   Used Available Use% Mounted on
udev               1021784      0   1021784   0% /dev
tmpfs               205244   4348    200896   3% /run
/dev/sda1          8189368 660344   7093312   9% /
tmpfs              1026204      0   1026204   0% /dev/shm
tmpfs                 5120      0      5120   0% /run/lock
tmpfs              1026204      0   1026204   0% /sys/fs/cgroup
tmpfs                51200     12     51188   1% /var/log
tmpfs              1026204      0   1026204   0% /tmp
tmpfs                10240   1480      8760  15% /DietPi
192.168.178.28:/   8123904 799744   6888448  11% /mnt/VM-Jessie
root@VM-Stretch:/mnt# l /mnt/VM-Jessie
total 16
drwxrwxr-x 2 dietpi dietpi 4096 Jul 18 17:51 downloads
drwxrwxr-x 2 dietpi dietpi 4096 Jul 18 17:51 Music
drwxrwxr-x 2 dietpi dietpi 4096 May 20 18:59 Pictures
drwxrwxr-x 2 dietpi dietpi 4096 May 20 18:59 Video

Veeeery interesting, when giving path, it connects via v3, even that v4 is enabled:

root@VM-Stretch:/mnt# mount -t nfs -v 192.168.178.28:/mnt/dietpi_userdata /mnt/VM-Jessie
mount.nfs: timeout set for Thu Jul 19 14:13:27 2018
mount.nfs: trying text-based options 'vers=4.2,addr=192.168.178.28,clientaddr=192.168.178.29'
mount.nfs: mount(2): Protocol not supported
mount.nfs: trying text-based options 'vers=4.1,addr=192.168.178.28,clientaddr=192.168.178.29'
mount.nfs: mount(2): No such file or directory
mount.nfs: trying text-based options 'addr=192.168.178.28'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 192.168.178.28 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 192.168.178.28 prog 100005 vers 3 prot UDP port 43217

So:

  • Not only the NFS server, but also client needs netbase package to be installed, when connecting to NFSv3 server.
  • When connecting to NFSv4 server, you must not add a path to the server IP, just 192.168.0.100:/
  • When connecting to NFSv3, then the path is needed: 192.168.0.100:/path/to/export

So last thing to check, is why netbase is needed now (and not on v6.9), as it didn't get uninstalled on v6.10+ patch, AFAIK (no dependency of net-tools, never watched it being purged).

€: Hah:

[  OK  ] DietPi-Software | APT upgrade, please wait...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
The following packages were automatically installed and are no longer required:
  libbsd0 libedit2 libopts25 netbase
Use 'apt autoremove' to remove them.
The following packages have been kept back:
  linux-image-amd64
The following packages will be upgraded:
  base-files ca-certificates dirmngr dpkg gnupg gnupg-agent gpgv
  intel-microcode libgcrypt20 libldap-2.4-2 libldap-common libsystemd0
  libudev1 perl-base systemd systemd-sysv udev
  • Interesting, even without apt update my v6.9 snapshot directly offers to autoremove those packages. I am pretty sure that was not the case, as I left that snapshort very clean, directly after running DietPi-PREP on it.

So I am not sure how the dependencies/autoremove handling can change without an actual list update, but perhaps the package priorities (required, important, optional, extra, ...) are checked directly from the current repo? Then netbase priority changed from required (not autoremoved) to important?

Hmm another thing found on Jessie:

root@VM-Jessie:~# apt-cache depends net-tools
net-tools
  Depends: libc6
  Conflicts: <ja-trans>
  Conflicts: <ja-trans:i386>
  Replaces: <ja-trans>
  Replaces: <ja-trans:i386>
  Replaces: netbase
  Replaces: <netbase:i386>
  Conflicts: net-tools:i386
  • net-tools replaces netbase?? But both packages are installed side by side...

Ah, just certain old version, it seems:

root@VM-Stretch:~# apt depends net-tools
net-tools
  Depends: libc6 (>= 2.14)
  Depends: libselinux1 (>= 1.32)
  Conflicts: <ja-trans> (<= 0.8-2)
  Replaces: <ja-trans> (<= 0.8-2)
  Replaces: netbase (<< 4.00)

Just verified: Purging netbase and installing net-tools leads to mount error again.

MichaIng picture MichaIng on 19 Jul 2018

Okay added commit. I hope it solves the issue for you guys as well: https://github.com/Fourdee/DietPi/commit/f56c1803c16256a782bfece3ebde8090a810bd47

@Fourdee
Ideally we somehow need to check within drive_manager if NFS server is v4 or v3 (and below) to additionally let user add path to NFS export conditionally, as:

  • With path, client will always connect via NFSv3, even that NFSv4 is supported.
  • Without path, client will not connect at all to NFSv3 (permissions issue).

Just found the system boot hanging, when NFS server is down. Shall we add nofail to network drives as well, otherwise noauto,x-systemd.automount? Just tested, both is enough to avoid hanging. noauto,x-systemd.automount sadly does not auto mount NFS drive on boot, although this is how it should work: https://wiki.archlinux.de/title/Fstab

MichaIng picture MichaIng on 19 Jul 2018
❤1 👍1

Thanks @MichaIng, I did a quick test adding netbase this morning, on my 6.11 test Pi, and that also fixes the problem for me:

root@DietPi:~# apt-get install netbase
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
  netbase
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 19.1 kB of archives.
After this operation, 45.1 kB of additional disk space will be used.
Get:1 http://mirror.reap.net.nz/raspbian/raspbian stretch/main armhf netbase all 5.4 [19.1 kB]
Fetched 19.1 kB in 1s (18.3 kB/s)
Selecting previously unselected package netbase.
(Reading database ... 16870 files and directories currently installed.)
Preparing to unpack .../archives/netbase_5.4_all.deb ...
Unpacking netbase (5.4) ...
Setting up netbase (5.4) ...
root@DietPi:~# mount -t nfs -v 192.168.1.10:/mnt/user/music_test /mnt/test/
mount.nfs: timeout set for Thu Jul 19 20:40:53 2018
mount.nfs: trying text-based options 'vers=4.2,addr=192.168.1.10,clientaddr=192.168.1.21'
mount.nfs: mount(2): Invalid argument
mount.nfs: trying text-based options 'vers=4.1,addr=192.168.1.10,clientaddr=192.168.1.21'
mount.nfs: mount(2): Protocol not supported
mount.nfs: trying text-based options 'vers=4.0,addr=192.168.1.10,clientaddr=192.168.1.21'
mount.nfs: mount(2): Protocol not supported
mount.nfs: trying text-based options 'addr=192.168.1.10'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 192.168.1.10 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 192.168.1.10 prog 100005 vers 3 prot UDP port 33776
root@DietPi:~# ls -l /mnt/test
total 8
drwxrwxrwx 1 99 users   36 Jan  7  2017 2L
drwxrwxrwx 1 99 users 4096 Dec 11  2014 linn 24bits of xmas
drwxrwxrwx 1 99 users 4096 Dec 16  2013 Stereophile Test CD, Vol. 1
drwxrwxrwx 1 99 users   43 Aug  7  2017 Various Artists
root@DietPi:~#

WRT:

Just found the system boot hanging, when NFS server is down. Shall we add nofail to network drives as well, otherwise noauto,x-systemd.automount? Just tested, both is enough to avoid hanging. noauto,x-systemd.automount sadly does not auto mount NFS drive on boot, although this is how it should work: https://wiki.archlinux.de/title/Fstab

I also found I had to add nofail in the fstab entries I had added manually, to prevent boot hangs if the remote share is down. So my manual fstab entries use auto,nofail.

duncansimpson picture duncansimpson on 19 Jul 2018

Okay, nofail added to network drives as well. Only thing that is outstanding is:

  • NFSv3 needs the path to the export dir added to mount command and fstab entry.
  • NFSv4 needs just <IP>:/. If path is added, v4 connection attempts will fails and connection will be v3. If server is v4 only, then connection will completely fail.

Thus, currently dietpi-drive_manager cannot be used to add v3 drives directly (uses v4 method). To enable this we would need to identify, which version the server is, properly just via test mounting and catch failure, and in case ask user to verify v3 server enter path as well... Some testing, some good thoughts and ideas needed, thus moved to v6.13 😄.

I will close this issue, as initial problem is solved.

MichaIng picture MichaIng on 20 Jul 2018
👍2 ❤1

@MichaIng
Not sure if this is the right place or if I should open a new issue but we have a report on our forum about failed NFS mounts

https://dietpi.com/phpbb/viewtopic.php?f=9&t=7422

Drive Manager creates an /etc/fstab entry that leads to the fact that the NFS share is mounted during boot. On my test this fails as well because eth interface was not yet online.

So I see 2 solutions

  1. execute NFS mounts after eth interface is online
  2. change mount options in /etc/fstab to nfs _netdev,nofail,noauto,x-systemd.automount 0 0
Joulinar picture Joulinar on 26 Mar 2020

@Joulinar
Many thanks for reporting. Jep I saw it on forum as well. Very strange since noauto should not make it mount on boot and _netdev should force it to wait with mount for network at least. Probably these two options do not work well together in all cases 🤔.

Could you check journalctl -u mnt-mountpoint.mount; journalctl -u mnt-mountpoint.automount (replacing "mountpoint" with the actual one of course)? When having the mount timestamps we're probably able to find what is accessing the mount point or might otherwise force the automount.

MichaIng picture MichaIng on 26 Mar 2020

@MichaIng
The NFS mount is done right in between assigning IP address using DHCP. Means between DHCPDISCOVERand DHCPOFFER

root@DietPi3:~# journalctl -u mnt-nfs_client.mount
-- Logs begin at Thu 2019-02-14 11:11:58 CET, end at Thu 2020-03-26 10:11:41 CET. --
Mär 26 10:10:42 DietPi3 systemd[1]: Mounting /mnt/nfs_client...
Mär 26 10:10:42 DietPi3 mount[427]: mount.nfs: Network is unreachable
Mär 26 10:10:42 DietPi3 systemd[1]: mnt-nfs_client.mount: Mount process exited, code=exited, status=32/n/a
Mär 26 10:10:42 DietPi3 systemd[1]: mnt-nfs_client.mount: Failed with result 'exit-code'.
Mär 26 10:10:42 DietPi3 systemd[1]: Failed to mount /mnt/nfs_client.

EDIT: missed the automount feedback. There is an entry only, once I switch /etc/fstab to x-systemd.automount

root@DietPi3:/mnt/nfs_client# journalctl -u mnt-nfs_client.automount
-- Logs begin at Thu 2020-03-26 10:18:02 CET, end at Thu 2020-03-26 10:19:26 CET. --
Mär 26 10:19:26 DietPi3 systemd[1]: mnt-nfs_client.automount: Got automount request for /mnt/nfs_client, triggered by 777 (bash)
root@DietPi3:/mnt/nfs_client#

EDIT2: NFS mount will succeed using STATIC IP instead of DHCP

Joulinar picture Joulinar on 26 Mar 2020

@Joulinar
Okay, so my guess is that the _netdev overrides the noauto option. If you remove _netdev from fstab and leave noauto,x-systemd.automount only, does it work then?

_netdev AFAIK result in an After=network.target or After=network-online.target in the systemctl cat mnt-mountpoint.mount systemd unit, and sadly After=network-online.target does not result in what one expects. The /etc/network/interfaces entries with allow-hotplug are not handled by networking.service but via hotplug udev rules, which create [email protected] like services once the network adapter is ready. These services are Type=simple (default) which means that network-online.target is already reached when ifup STARTS to do something instead of after it has FINISHED. So in case of DHCP it takes a while until interface setup has finished while the target is reached earlier hence the network mount is attempted too early.

I am thinking if we should override ifup@<iface>.service to be Type=oneshot for all configured network interfaces, which gives network-online.target much more meaning and makes our network check in dietpi-boot basically obsolete. We could instead simply add After=network-online.target to dietpi-boot.service then. Would resolve some other related issues.

Debian btw had Type=oneshot (or forking) in the past, but they removed it because in some cases it leads to hanging boot, when some interface fails or hangs on configure. But actually it simply makes sense to hang boot when anything depends on network. It will by default hang for 90 seconds max and we can even adjust this to wait for max 10 seconds instead or similar (AFAIK), e.g. editable by user.

Okay long story short, if removing _netdev from fstab works fine already, this is the fix that we can apply for now.

MichaIng picture MichaIng on 26 Mar 2020

@MichaIng
just to avoid any confusion. The original fstab entry is nfs auto,_netdev,nofail. So it's auto instead of noauto. I changed it as follow:

from: nfs auto,_netdev,nofail
to nfs _netdev,nofail,noauto,x-systemd.automount

I used a SAMBA entry as example that is created by Drive Manager

Joulinar picture Joulinar on 26 Mar 2020
👍1

@Joulinar
Ahhh, dammit we added automount for samba only. Needs to be added for NFS reasonably as well. Okay with automount the issue is solved then?

MichaIng picture MichaIng on 26 Mar 2020

yep correct, changing to same syntax like samba is fixing it. What I'm not sure about is using the dump and fsck numbers at the end like

nfs _netdev,nofail,noauto,x-systemd.automount 0 0

At least I have seen it on this old forum entry https://dietpi.com/phpbb/viewtopic.php?p=13341#p13341

Joulinar picture Joulinar on 26 Mar 2020

@Joulinar
The two numbers can indeed be omitted as they default to 0 anyway then. Okay great, not sure why we did not add this together with Samba that time, it definitely makes sense anyway to not open/keep-up a network share connection before it is actually used.

MichaIng picture MichaIng on 26 Mar 2020
👍2

I guess sooner or later I would need to learn how to create RP's on Git. That way we don't need to wast your time always for such simple thinks.

Joulinar picture Joulinar on 26 Mar 2020
👍1

@Joulinar
Lol we had this already, but missed the NFS pre-v3 fstab entry while the NFSv3 entry contained the automount + noauto already: https://github.com/MichaIng/DietPi/commit/173589be5b131a015fd31153bef91bcac05ef021
Changelog: https://github.com/MichaIng/DietPi/commit/c8db97e7491997387680ef57f0a2b89774a76194

I guess sooner or later I would need to learn how to create RP's on Git. That way we don't need to wast your time always for such simple thinks.

Not too hard. Select a file (from dev branch), click edit, do your changes in GitHub file editor, choose a new branch below to send the commit to. It will redirect to open a pull request against the base branch (dev).

MichaIng picture MichaIng on 26 Mar 2020
😄1
Was this page helpful?
0 / 5 - 0 ratings

Related issues

bhaveshgohel picture bhaveshgohel  ·  3Comments
oshank picture oshank  ·  3Comments
1021683053 picture 1021683053  ·  3Comments
Fourdee picture Fourdee  ·  3Comments
aesirteam picture aesirteam  ·  3Comments