I should preface this with the information that I am running openSUSE Tumbleweed. Others may not have quite the same problem but the fundamentals are an issue for me so this is what I found:-
Summary of Findings
When using an NFSv4-only server (with fsid=0 configured), OSMC/Kodi is unable to browse or detect the NFS server via the GUI’s "Add Videos > Browse > NFS" interface, even though the server is accessible, correctly exported, and reachable.
Other NFSv3-exporting devices (NAS units) do appear in the NFS browser, confirming that the discovery mechanism is NFSv3-specific.
Attempting to manually add an NFSv4 path in the GUI (via “Add Network Location...”) also fails, even when the path is correct and matches what is exported with fsid=0.
The only reliable method to access NFSv4 exports from OSMC is to mount the NFSv4 share manually via the command line on the Vero, and then point Kodi to the local mount path (e.g. /mnt/nfs_vids) using the “Root Filesystem” browser in the GUI.
Workaround That Works
Mount NFSv4 share on the Vero:
sudo mount -t nfs -o vers=4 192.168.x.x:/SharedFolder /mnt/<some_folder>
In Kodi GUI:
Browse to Root filesystem > mnt > some_folder
Add the source from there
This method is reliable and bypasses the GUI/NFSv4 compatibility issue. Suggested Outcome
It would be helpful if:
The OSMC Wiki could include a section on how to correctly access NFSv4-only servers
The Kodi GUI could eventually support browsing NFSv4 exports directly
If not possible, a clear warning or guidance in the GUI could point users to the need for manual mounting or NFSv3 support
Thank you for your outstanding work on the Vero platform. I hope this report contributes to an even better user experience and that I have not made a fundamental error here.
Hi Sam,
I spent a good deal of time on this and am still not happy with my solution because the mounting is not reliable after a reboot and needs to be repeated as it depends on sequence of actions.
The short answer to your question is I cannot mount using the app. Discovery is also a problem because nsfv3 is blocked.
I am busy just now but when I have time I shall get back to this as I do want to get it working without recourse to cli. Will report solution when found.
In short yes. AFAIK kodi relies on discovery using rpc-bind and mountd which are normal for nfsv3 but not needed for nfsv4. I have now changed the configuration so that NFSV3 is allowed opened these protocols in the firewall and opened the required ports for udp as well as tcp. I can now browse to and select the exported directory but I have not yet been able to get a connection. I have checked the permissions and they are all OK. Will keep working on this and report back.
As Chris suggested I used automount but here is the detailed report of what I have been doing, with help from ChatGPT I confess:-
Report: NFSv4-only Compatibility Issues in OSMC (Vero V)
System setup:
Server: openSUSE Tumbleweed (.137), running NFSv4-only
Encrypted disk mounted at /run/media/alastair/10TB_Disk
Exports defined in /etc/exports:
NFSv3 and NFSv2 explicitly disabled via /etc/sysconfig/nfs:
NFSD_OPTIONS=""
NFS3_SERVER_SUPPORT="no"
NFS4_SUPPORT="yes"
Verified via rpcinfo -p: only 100003 4 tcp 2049 nfs is listed (NFSv4)
Client: OSMC (Vero V), up to date
Using Kodi’s built-in NFS client via GUI
Observed behaviour:
Vero was able to discover other NFSv3-exporting devices on the network using Kodi's GUI (Browse > NFS).
The .137 server did not appear under GUI NFS browsing.
Manual mounting using NFSv4 on the Vero via CLI worked flawlessly:
sudo mount -t nfs -o vers=4 192.168.169.137:/Archived_data /mnt/nfs_vids
Adding this mount point as a source in Kodi via Root Filesystem → /mnt/nfs_vids worked as expected — all files accessible.
Attempts to force Kodi’s GUI browser to connect to an NFSv4 server consistently failed with:
“Couldn’t retrieve directory information. This could be due to the network not being connected.”
Conclusions:
Kodi’s NFS client in OSMC relies on NFSv3-style discovery (via mountd) and does not support NFSv4-only server browsing via GUI.
Kodi’s internal handling of NFSv4 mounts appears to require manual mounting on the client system.
This is not intuitive for users following modern security recommendations (e.g. disabling NFSv3).
Suggestions:
Improve GUI support for NFSv4-only servers — either via:
Proper browsing of fsid=0 root and subpaths
Allowing manual entry of NFSv4 paths in the "Add network location" dialog
Document best practices for using Kodi with NFSv4-only exports
Including CLI-based mount setup
Advising users how to safely handle automounting (e.g. fstab with x-systemd.automount)
Ideally: enhance Kodi’s NFS client to handle NFSv4 mount negotiation directly, removing the dependency on legacy NFSv3 discovery mechanisms.
I know this is very cheeky but it sums up quite a lot of effort and digging on my part. Hope it agrees with your own view on the way forward.
Regards,
Budgie
I think the best option is to bump libnfs and hope for the best.
We don’t package it downstream anymore (but used to). It became stable enough that this was no longer necessary but we may need to revisit.
I’ve been using nfsv4 for years now. I like using /etc/fstab to handle the mounting.
In the example below replace nfs.server.example with the hostname of your nfsv4 server, can also use an IP address if you don’t have a DNS server. Notice I’m using nfs 4.2 so modify that as well for your own needs. You may or may not want to mount read only as I do, so that’s another change you may want to make.
It’s been awhile but I think the /mnt directories will get made automatically, if not just create them first.
Summary of Findings
Workaround That Works
Suggested Outcome
Conclusions:
Suggestions: