NFS Access/Mount

Hi, recently installed DietPi onto my Rasp Pi 2. All is well. Thought it would be a good little low power device to use for an Emby server. (I don’t need transcoding and I don’t server to more than 1 client at a time).

I have a Synology NAS with NFS setup. Kodi (installed on an Odroid C2) successfully accesses the NFS shares at: nfs://192.168.0.11/volume1/video/Movies

So I installed Emby, and when attempting to add source folders I obviously couldn’t reach my server.

I Installled NFS Client, however when accessing it to input my server IP (192.18.0.11) it fails to connect:

──────────────┤ DietPi-Config ├───────────────────────────────────────────────────┐
     │ Samba client : Unable to connect and/or incorrect details                                                            │ 
     │ FTP client   : Not Installed                                                                                         │ 
     │[b] NFS client   : Unable to connect and/or incorrect details      [/b]                                                      │ 
     │ NoIp status  : Not Installed                                                                                         │ 
     │ Apt mirror   : http://raspbian.raspberrypi.org/raspbian                                                              │ 
     │ NTPD mirror  : debian.pool.ntp.org                                                                                   │ 
     │

I had a search and it appears some people are editing /etc/fstab (e.g. https://dietpi.com/forum/t/connect-to-nfs-server/652/1) but when attempting to run edit /etc/fstab I get:

Warning: unknown mime-type for "/etc/fstab" -- using "application/octet-stream"
Error: no "edit" mailcap rules found for type "application/octet-stream"

I’m not the best with Linux commands, but willing to learn - so any pointers or links to guides would be great. Thanks.

I have similar setup with QNAP NAS, Kodi on Odroid C2 (LibreELEC) and Emby server on a Z83 running DietPi.

In /etc/fstab on the Z83 I have the QNAP shares mounted as follows:

192.168.1.4:/Multimedia/Movies /mnt/Movies nfs rsize=8192,wsize=8192,timeo=14,intr,nofail,noauto,x-systemd.automount 0 0

I have the Kodi-Emby plugin installed on the C2.

Sounds like NFS isn’t working on your Pi? Have you tried a manual install of NFS client? And how are you trying to edit /etc/fstab?

John

I have the Kodi-Emby plugin installed on the C2.

I want the same on my C2 (well I already have it, but the Emby server is just a test one installed on my MacBook). And I also want MRMC pointing to Emby on an Apple TV 4 (the wife loves the ATV UI, the remote and the fact it has all the other services (Netflix, iTunes Movies etc.) on one box so she doesn’t have to mess about changing inputs, changing Harmony settings etc.). The ATV in the lounge and the C2 in my mancave.

Curently I just use MRMC on the ATV and LibreELEC/Kodi on the C2, and manually update watched stauses between clients by running a library update which in turn triggers a Trakt sync.

Sounds like NFS isn’t working on your Pi? Have you tried a manual install of NFS client?

Maybe, I just installed it through the “Optimized Software” GUI option.

I haven’t installed NFS Client manually. Not sure how to go about it. I’ll have a search. I’m guessing I have to uninstall the current version first?

And how are you trying to edit /etc/fstab?

Sorry was a bit burried in my original post. I log in via SSH and then run:

edit /etc/fstab

The output I get is:

“Warning: unknown mime-type for “/etc/fstab” – using “application/octet-stream”
Error: no “edit” mailcap rules found for type “application/octet-stream””

I tried searching for a solution and it appeared the problem was the lack of a text editor? I tried installing VI, but it failed and that’s when I decided to post on here for help, ha.

nano /etc/fstab

Was what I was after. Going to tinker now.

This was a useful link if anyone stumbles across this thread:

https://www.htpcguides.com/configure-nfs-server-and-nfs-client-raspberry-pi/

So my fstab looked like this:

192.168.0.11:/ /mnt/nfs_client nfs4 auto,_netdev 0  0

I tried removing the 4:

192.168.0.11:/ /mnt/nfs_client nfs auto,_netdev 0  0

Rebooted, still no luck.

Tried a modified version of johnvick’s line:

192.168.0.11:/volume1/video /mnt/nfs_client nfs rsize=8192,wsize=8192,timeo=14,intr,nofail,noauto,x-systemd.automount 0 0

and

192.168.0.11:/ /mnt/nfs_client nfs rsize=8192,wsize=8192,timeo=14,intr,nofail,noauto,x-systemd.automount 0 0

But no luck. Emby can’t find the share.


Also when I go into dietpi-config → 8 Network Options: NAS/Misc → NFS Client:

I enter my IP address and OK, it attempts to mount but then displays an error message very quickly. I can only catch something like “mount error 13”. But there is more text that disappears too quickly.

I know I’m just talking to myself now. But the following works, may have been a reboot that fixed it, not sure:

192.168.0.11:/volume1/video /mnt/nfs_client nfs rsize=8192,wsize=8192,timeo=14,intr,nofail,noauto,x-systemd.automount 0 0

Can browse to /mnt/nfs_client and all my nfs folders are there.

Got there in the end. :sunglasses:

Thanks for letting us know. I don’t know much about NFS, but maybe the path to /volume1/video is needed due to NFS permissions restricted to that? Not sure about the other fstab options, but will check out. Maybe we can tweak these a bid and/or do some better checks for debugging within NFS mount attempts.

but maybe the path to /volume1/video is needed due to NFS permissions restricted to that?

It’s possible. I’d have to check.

Maybe we can tweak these a bid and/or do some better checks for debugging within NFS mount attempts.

Yeah would help no doubt. I think the main pain points were:

  1. NFS Client defaults to nsf4 without any indication - maybe some sort of option/checkbox to enable disable nfs4 over nfs.
  2. There’s a message with an error code that flashes up very very quickly when attempting to mount via NFS Client. I’m sure there’s a way of obtaining it, but I don’t know how. Maybe allowing that error to persist until a keypress would be useful.

Btw. Network drive mounting with v6.10 is fully integrated into dietpi-drive_manager, which got some huge rework with v6.10 (release yesterday). Would be great to check, if this now works or the error stays the same.

Haha. I can only laugh.

So… I get home from work and my Emby server had fully synced up and downloaded all metadata etc. Odroid with LibreElec and my Apple TV with MRMC can access it. All good.

I’d installed DietPi on my backup/test mSD card. So I thought I’d install it on my faster, larger mSD to squeeze out more performance. Install goes well.

First issue:

dietpi-config -> 8 Network Options: NAS/Misc

No longer exists. I can’t find any NAS/nfs options. I’m glad you mentioned it’s been reworked I thought I was going mad. I guess more tinkering now to find the new locations for nfs options.

Found the new options. But defaults to nsf4. So gives this error:

I’ll try fixing manually again.

No luck trying to run the command manually.

root@DietPi:~# mount -t nfs -o port=2049 192.168.0.11:/volume1/video /mnt/nfs
mount.nfs: mount point /mnt/nfs does not exist
root@DietPi:~# sudo mkdir -p /mnt/nfs
root@DietPi:~# mount -t nfs -o port=2049 192.168.0.11:/volume1/video /mnt/nfs
mount.nfs: Protocol not supported
root@DietPi:~#

Ok fixed it. Enabled NFSv4 support on my Synology (not sure what the repercussions are). All existing NFS access remains fine though and now the new dietpi-drive_manager wizard successfully mounts as expected. Can browse to /mnt/nfs/ and see my shares.

Installed Emby and all appears to be well.

Post wizard success message:

dietpi-drive_manager screen once mounted:

Quizzer
So finally it showed “protocol unsupported” messages when using mount -t nfs4 as well as with mount -t nfs?
And when enabling nfs4 support on NAS, both commands work?

I opened an issue about this on GitHub, feel free to join there as well, maybe we get this fixed for v6.11 hotfix update: https://github.com/Fourdee/DietPi/issues/1898

Hi guys, I’m seeing a similar issue since updating from 6.9 to 6.11

I have some NFSv3 shares on another server that mounted fine on 6.9 and earlier, and now fail to mount since updating from 6.9 to 6.11.

The original fstab entry was:

192.168.1.10:/mnt/user/music_test    /mnt/nas/music_test nfs               auto,nofail          0 0

Trying to mount that mount point manually:

root@DietPi:/mnt# mount -v /mnt/nas/music_test
mount.nfs: timeout set for Sun Jul  8 10:58:35 2018
mount.nfs: trying text-based options 'vers=4.2,addr=192.168.1.10,clientaddr=192.168.1.9'
mount.nfs: mount(2): Invalid argument
mount.nfs: trying text-based options 'vers=4.1,addr=192.168.1.10,clientaddr=192.168.1.9'
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.9'
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:/mnt#

Trying a test mount explicitly specifying nfs3 also fails:

root@DietPi:/mnt# mount -t nfs -o vers=3 -v 192.168.1.10:/mnt/user/music_test /mnt/test/
mount.nfs: timeout set for Sun Jul  8 10:59:56 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:/mnt#

The server in this case is an unRAID based on Slackware, which only supports NFSv3, so I can’t enable v4 per @Quizzer’s fix.

Hi MichaIng, I think you’ve captured it well on git.

  • The new dietpi-drive_manager woks fine with NFSv4.
  • The new dietpi-drive_manager fails with older versions of NFS as experienced by myself and @dunc.

If you need me to test anything else let me know.