Best options for NFS mount?

Help and Support
4

That thread is possibly getting just a little more technical then perhaps you need :slightly_smiling:.

If you’re lucky, @DBMandrake will chip in here as he has not only NFS knowledge, but more importantly here specific knowledge of getting your media through NFS on OSMC on these platforms. But don’t think he’d disagree too much with this summary:

  1. Don’t use libNFS (entering “nfs://…” URIs into Kodi). [[Edit: Thanks to @TheRookie I’ll qualify that with “Unless you’re sharing your configuration between different Kodi systems and/or libNFS works fine for you anyway” :slightly_smiling:]].
  2. Do mount the NFS shares manually by entering them in “/etc/fstab”. You will need to create a suitable directory somewhere to mount the share - please don’t create it under “/media/” …
  3. Mount options …
    3.1 “noauto,x-systemd.automount” - Debian/Raspbian “magic” to get the filesystem to mount automagically at boot.
    3.2 “noatime” - Don’t update the access times on files. This will prevent your “RPi” from trying to write that information back to the NAS. That may cause you issues if you’re accessing the same media with anything else, which uses the file access time to determine whether something has been watched or not. If that’s not an issue to you, it’s probably worth including just because there’s no need for the “RPi” to write that information back. If you are going to set that, there are other options (such as “nodiratime”) which you might also want to add, for consistency.
    3.3 “async” - ignore that; that was from an example from a much older system.
    3.4 “nfsvers=3” - that will force your NAS and your “RPi” to talk using NFS version 3. If you don’t specify this, if your NAS supports it, you’ll probably use NFS version 4. If you’re running modern “RPi” hardware, and if your NAS does support it, that might work better for you - Try it and see.
    3.5 “rsize=8192” (and “wsize=8192”) - That’s a … subject of discussion between myself and @DBMandrake :slightly_smiling:. I’d say (if you’re using modern “RPi” hardware, based on the discussion we’ve been having in the other thread) then do not specify either - let the operating system decide what’s best. @DBMandrake may disagree, but again I don’t think he would disagree with “If you’re interested then try changing it and see what happens” :slightly_smiling:
    3.6 “nolock” (and “local_lock=all”) - Disables file locking. Personally I’ve not seen any evidence that the software does any file locking, so I’d say leave those out, purely on the K.I.S.S. principle.
    3.7 “retrans=2” - Tweaks one particular part of the NFS protocol; personally I’d leave it out and use the kernel default (typically 2 or 3 anyway).
    3.8 “soft” - This affects how errors are handled (… plus some other tweaks we don’t need to worry about …), particularly the NFS server going away. I come from somewhat different a background from @DBMandrake and aren’t used to NFS servers going away :slightly_smiling:. I’d always use hard mounts, but in this case, @DBMandrake is entirely correct and a soft mount is the best option.
    3.9 “tcp” - This was also the subject of some discussion, but I believe the consensus was that if you’re running later “RPi” hardware, tcp is what you want; if older then you might want to use udp (in which case you will need to adjust your rsize down to 8192). If you do use NFSv4, you’ll have no choice - that only supports TCP.
    3.10 You might want to add “ro”, as you say it is only for read access. That will mount “Read Only” (and also mean you won’t need options such as “noatime”).

That’s just from me; I the believe the team are working on this sort of thing at the moment, so I’m sure at some point there will be an official recommendation as to how to do this; for the moment, that will hopefully give you what you need.

1 Like