Mounting NFS shares is only relevant for Linux servers, correct?

I am not Linux-fluent, but mounting NFS shares is only relevant for Linux servers, correct?

Usually, as NFS server is not something natively supported with desktop versions of Windows, but there is software that you can run on Windows to add this capability. SMB/Samba should give all the performance you would need without going this route.

1 Like

I briefly went down this road before and I do use SMB on any Linux boxes that I used to access my windows server. However I still find the subject intriguing. Is there some kind of free NFS server for windows you are aware of? It was a while back but I recall on my searches I think I only found one commercial solution.

It is not something Iā€™ve actually played with but whenever someone around here has mentioned it they are using Hanewin from what I remember seeing. I donā€™t see anything about paying money on their site so I assume it is free. I think @angry.sardine has some experience on this topic and using this software IIRC.

Hanewin NFS Server. It is technically shareware, but thereā€™s no built-in expiry date or anything, so you can use it for free for as long as you donā€™t feel guilty about it. :slightly_smiling_face:

I donā€™t claim any sort of expertise, here, but I can provide a list of the settings Iā€™m using if thatā€™s useful.

That said, if one is willing to use autofs (or fstab) the performance you can get out of a remote SMB share is just as fast as you can get from NFS nowadays, and thatā€™s probably a little less hassle.

2 Likes

I guess Iā€™m a geek at heart even though I donā€™t know a lot about this subject or Linux in general. I like trying stuff! Iā€™m not doing this today, but if you donā€™t mind PMing me with settings (or here is fine with me if itā€™s fine with you) I will save them so they make sense when I try it!

I think the interesting thing about NFS is that it would allow me to browse my Windows shares with Linux clients. I have a bunch of them for various purposes and itā€™s a pain to have to configure each of them separately for each purpose, especially in cases where I am mapping media folders on multiple Kodi/Android players like I do. I use PfK on some of them which handles the mappingā€¦somehow like magicā€¦but I think it might open more possibilities to have the NFS option.

There is also a setting in OSMC for ā€œautomountā€. I havenā€™t dug into that yet, but it seems like that would require NFS to function as well wouldnā€™t it?

If nothing else the folks that make that program also do some other creative stuff!

https://www.hanewin.net/rpi/remote-rpi-boot.htm

Hi,

You can already do this with samba.

With these I suspect you will need to use kodi mounts (libnfs), even if NFS on windows offered improvement over samba, it would be lost if you canā€™t take advantage of kernel mounts (autofs or fstab).

NFS on a linux server makes sense to me, as is it often easier to configure and offers better throughput for clients who can take advantage of kernel mounts. IMHO if youā€™ve got a windows server/pc offering the shares, its probably better to stick with samba.

If you are referring to the automount, that was in the topic this was originaly posted in. All this is sharing USB drives which auto-mounted under /media. This is then added for exports (shares) for the the NFS server.

Thanks Tom.

If your source is defined at Kodi level, then it is faster to read from a Hanewin NFS source rather than via SMB on the same Windows box (or at least it was the last time I checked); but an OS-level mount using autofs or fstab is faster than either.

It used to be the case that an autofs mount of NFS also outperformed an autofs mount of SMB, but somewhere along the line the performance of SMB mounts has improved dramatically. An autofs mount of SMB can now read at a speed that is limited by the gigabit Ethernet connection rather than by OS overhead. So if youā€™re using autofs or fstab then using Hanewin no longer has any speed advantage.

1 Like

If your issue is that you have multiple independent drives on a single Windows PC with media on them you can actually consolidate them and share them as one using Directory Junctions. I actually have my media like this, spread across five different drives, but I have a single shared folder that has directory junctions to the various media folders so they show up over the network in a single location. AFAIK this is the only type of symbolic link that will actually work this way and with Linux.

As for the multiple clients it is too much of a PITA to setup each from scratch and you donā€™t need to. If you look in Kodiā€™s userdata you will find a sources.xml and passwords.xml and these are the same across all Kodi clients and as such all you would need to do is copy the files and then in Video>files context menu and set content. No adding paths manually or browsing needed.

I think that is only true with SMBv1

There is a bit of a workaround in Kodi for that. If you go to video>files>add videos>browse>add network location> and then manually type in your IP address into the server name field (just host name or IP, do not add in smb://) along with your credentials in their respective place and hit okay this will give you a browsable network location for that machine and all of its (non-hidden) shares. This adds it for all aspects of the library and you can do something similar for file explorer in settings as well. Both get stored in your userdata under a file called mediasources.xml. This file (along with passwords.xml where your credentials are stored) can be transferred to other installs to ease the setup.

2 Likes

Really. I didnā€™t know that. So I take it if I do that on my Vero4K+, get it working so it can browse my Windows shares, I can copy the two config files you mentioned to any Kodi installation and it will work?

Currently I use the PfK add on only and this is what my sources file looks like:

<sources>
    <programs>
        <default pathversion="1"></default>
    </programs>
    <video>
        <default pathversion="1"></default>
        <source>
            <name>Auto-mounted drives</name>
            <path pathversion="1">/media/</path>
            <allowsharing>true</allowsharing>
        </source>
        <source>
            <name>3D MVC</name>
            <path pathversion="1">3D MVC</path>
            <allowsharing>true</allowsharing>
        </source>
    </video>
    <music>
        <default pathversion="1"></default>
        <source>
            <name>Auto-mounted drives</name>
            <path pathversion="1">/media/</path>
            <allowsharing>true</allowsharing>
        </source>
    </music>
    <pictures>
        <default pathversion="1"></default>
    </pictures>
    <files>
        <default pathversion="1"></default>
    </files>
    <games>
        <default pathversion="1"></default>
    </games>
</sources>

Not sure what ā€œpathversionā€ means, but I guess it has something to do with how the PfK add-on works?

sources.xml stores the paths for your libraries and these are what show up in video>files, music>files, etc.

mediasources.xml are what you will see when you go looking to add a new source as they are basicly just pointers to user defined locations be they network or local.

Passwords.xml is essentially path substitutions that when they see a matching url they substitute credentials into the path. It is plain text and shouldnā€™t be too hard to figure out how it works by looking in the file. I have a guide in how-to regarding path substitution that spells it out in detail if your curious

These three files copied over to another Kodi install on any platform only give you your sources setup with working file paths. The Kodi library, and the scraping settings are stored in a series of databases. If you were just copying these three files to get to a normal Kodi Library you would still have to context menu over each source location and do a set content to setup the scraping.

Donā€™t really want to comment on how any of this would interact with PKC as Iā€™ve not looked into the how exactly it does what it does.

In my personal setup I have a MySQL setup so with the above three files I also add my advancedsettings.xml which points to that and then that becomes a fully working Kodi library with just four files moved over. It makes testing a lot less painfull :grin:

Believe it or not you can move an entire userdata folder to most Kodi platforms and it will work. The notable exceptions would be that you should NOT copy guisettings.xml (where most of Kodiā€™s non-add-on settings are held) from an OSMC box to a different platform (or even swap them between a Vero and RPi install) and any binary add-ons (visualizations, PVR clients) are not going to work.

The pathversion=ā€œ1ā€ parameter means it was written with a more recent version of Kodi. Itā€™s to ensure that saved paths can be reliably updated if/when a new way to store them is implemented

Download Hanewin NFS Server from here: Networking Software for Windows
(You want the service installer).

Once installed, you should end up with a desktop shortcut called NFS Server. To configure it, right-click the shortcut and choose Run as Administrator (rather than simply double-clicking) then go into the Edit menu and select Preferences.

Here are my settings:

Hanewin A
Hanewin B
Hanewin C
Hanewin D

Obviously you need to set up your own Exports file, depending on which folders you want to export.

Iā€™m not claiming these are the best settings, but they seem to work for me.

At the Vero end, I create a folder under /mnt (angry-sardine-pc) and mount each of my five NFS exports in a subfolder below that, using a separate autofs mount for each. Then I create a single Kodi source, based on ā€œRoot Filesystemā€ which points to the parent folder (angry-sardine-pc) with file type set to none - call that nfs-mount. Then I go into Videos/Files, browse into nfs-mount, find all of the relevant subfolders within the structure, and set the content type for each to be Movies or TV as appropriate.

If you want, you can create a Kodi-level NFS source instead - Iā€™d still recommend a single source with subfolders tagged according to file type. A Kodi-level source is slower, but does have the advantage that you can have Kodi bring the server out of sleep mode with a WOL packet - I have yet to figure out how to do this with autofs.

You may also need to experiment with the Windows firewall rules a bit. I ended up creating rules for all three of the executables (nfsd.exe, nfssrv.exe, and pmapd.exe) and then separate rules to open up all four of the ports listed on the PortMapper tab in Preferences, for both TCP and UDP. (This is probably overkill).

1 Like

Some rough benchmarks I did just now gave me the following read speeds.

Kodi-level SMB: 192 Mb/s
Kodi-level NFS: 272 Mb/s
Autofs SMB: 904 Mb/s
Autofs NFS: 920Mb/s

So I still maintain there isnā€™t much need for Hanewin so long as youā€™re using autofs.

(Recall that the maximum allowed bit-rate for a 4K blu-ray is 128Mb/s).

2 Likes

Where exactly do you type this in? With Add Network Location I get a screen with Protocol (selectable), Server name, Shared folder, etc.

Things seem to have changed with Matrix. I can no longer type in smb://user:pass@192.168.x.x at the screen with ā€˜Enter a name for this media sourceā€™ at the bottom

The IP address (by itself, no smb:// or full UNC path) goes in the server name field. You can use a host name but then name resolution has to be done and IMO that just leads to potential issues. Iā€™ve not tried to add credentials as part of the file path in Matrix but one should absolutely NOT be trying to do that anyway. When you add the credentials as part of the path then your credentials get stored (over and over and over again) in the database which is not ideal. This will also make them show up in Kodiā€™s logs which is not good. In the adding network Iā€™m talking about there is boxes to enter the user/pass which gets added as part of passwords.xml and so they do not get stored in the db and can easily be changed from that file at any time. If you were adding a new source location (as opposed to a network location) then IIRC after you manually enter a UNC path and hit OK it will then ask for credentials on a second screen but only if they are not already saved (which they would be if added with the network location).

Tried it and I get ā€˜Invalid argumentā€™

I used this simple metod. NFS is much faster.
https://forum.kodi.tv/showthread.php?tid=330260

Sorry, my bad (It has been a while since I last did this instead of just copying xml files). In the add network location you donā€™t put in ā€œsmb://ā€ as that is automaticly being added by the protocol selection. I updated my screengrab with something that is correct. The name field would be only an IP address or hostname in isolation. I imagine the subfolder may be useful if you have more than one share on the same network location that needs different credentials.