NFS

From Official Kodi Wiki
Revision as of 21:15, 25 August 2011 by >Canadave (→‎NFS sharing from Linux)
Jump to navigation Jump to search

Introduction

Network File System, or NFS, is a way to share folders over a network, and is an alternative to SMB sharing. The main benefits of using NFS instead of SMB are its low protocol overhead and its use of simple UID's to authenticate users rather than username/password combinations. Its main disadvantage in comparison to SMB (a commonly-encountered protocol in Windows environments) is that it can be more complicated to set up in some cases, since many non-technical users are unfamiliar with configuring UNIX-based protocols. NFS is commonly found on all Linux/UNIX distributions, as well as on Mac OSX and Solaris.
NFS offers several features:
  • It is already incorporated in UNIX-like operating systems (such as Mac OSX), eliminating the need for additional software and services to be installed on your computer.
  • It allows for authentication by UID, thus eliminating the need to save usernames and passwords in XBMC source XML files (note, however, that this simple authentication also makes it more vulnerable to attacks; NFS should be only used inside a private LAN).
  • Once properly configured, NFS will allow your network shares to be seen and accessed by not only XBMC, but also any other machine on your network.
When configuring NFS shares to use as network sources for XBMC's music/video libraries, use the following format: nfs://1.2.3.4/absolute/exported/path (where "1.2.3.4" should be replaced with the IP of your NFS server, and "/absolute/exported/path" should be replaced with the exported directory). See the sections below for help configuring NFS shares on various devices' operating systems.
For more info on network sources for your music and video in XBMC, see Types_of_Media_Sources.

NFS sharing from Windows

For serving (sharing) files from Windows using NFS, there seem to be three choices:
  • Windows Server 2003 R2 and Windows Server 2008 have built-in NFS Server and Client through Subsystem for UNIX-based Applications (SUA). With 64-bit support, this solution supports files up to 4TB in size
  • Microsoft Windows Services for UNIX (SFU) available herefor Windows 2000, Windows XP Professional (NOT Home edition, without a hexedit hack), Windows 2003 Server, and Windows Home Server (based on 2003 Server). SFU is 32-bit only, which may mean it only supports files up to 2GB in size, according to some sources (this is unconfirmed). A good installation guide can be found here. Windows SFU will not install on Windows Vista or Windows 7, so there is no way to serve NFS from Windows Vista or Windows 7 with the possible exception of the haneWIN solution below, but it is unconfirmed if that works with Windows Vista/7.
  • haneWIN NFS Server for Windows - a shareware program that costs 19EUR for non-commercial use. Claims to work for "Windows 2000 and above."
For accessing files on an NFS server from Windows as a client, please be aware that:
  • accessing an NFS shared folder natively from within XBMC for Windows is not possible right now; porting the needed library (libnfs) is a work in progress with low priority at the moment, since it is very complex.
  • NFS shares can be mounted at the OS-level in Windows with the built-in SUA NFS client, available only in Windows Vista/7 Ultimate and Enterprise editions.
  • an NFS client is available for Windows 2000, XP Pro, 2003 Server, and WHS (Windows Home Server) through Windows Services for UNIX (SFU), mentioned above.

NFS sharing from Mac OSX

Introduction

NFS is built into Mac OSX (OS 10.5 and later), and thus no additional software is required to set up NFS shares on a Mac OSX device. For basic NFS setup guidelines on a Mac, click the appropriate link:


Configuring NFS sharing from Mac OSX (Leopard and Snow Leopard) for use with XBMC

Note: The following assumes some basic knowledge of the UNIX/BSD operating system interface and environment, and assumes you are familiar with using Mac's Terminal command-line utility.

1. To allow regular (non-root) users to connect to your NFS shared folders, you'll need to edit the "/System/Library/LaunchDaemons/com.apple.nfsd.plist" file. Open it and add the option "-N" to the startup parameters as follows: 

 <array>
   <string>/sbin/nfsd</string>
   <string>-N</string>
 </array>

If you don't do this step, XBMC will only be able to access the Mac's shared NFS folders if XBMC is running as root (normally, XBMC does not run as root).

2. Configuration of the NFS server is done in a config file named "exports", located in the /etc directory. To view the current contents of "exports", execute the following command in a Terminal window: 

 cat /etc/exports

An example of a basic configuration for exporting a path with NFS looks like this: 

 /nfs/export -mapall=nobody -alldirs <ip>

By changing some of the options of that line we can realise 3 different approaches see the linux section for this and try to adapt according to the given examples for Mac OSX.


Examples of exported paths

In this sample "exports" file, we've set up several folders to be shared via NFS, using various parameters and options. The folders are named to indicate some things about how we've set them up; obviously, on your system, the folder names would be things like "video", "music", and so on. 

 /nfs/allread                -ro -mapall=nobody -alldirs
 /nfs/allwrite               -mapall=nobody -alldirs -network 192.168.1.0 -mask 255.255.255.0
 /nfs/writeAsMemphis         -mapall=501 -alldirs 192.168.1.5
 /nfs/xbmcuser

Let's look at each of these shared folders in turn.

  • The path "/nfs/allread" can be accessed from all computers (no ip given), is read-only ("-ro"), and access rights for a user named "nobody" are used ("-mapall=nobody").
  • The path "/nfs/allwrite" can be accessed from all computers on the subnet 192.168.1.0/255.255.255.0, has read and write permissions (we've omitted "-ro"), and again access rights for user "nobody" are used ("-mapall=nobody").
  • The path "/nfs/writeAsMemphis" can be accessed from the computer with an IP of 192.168.1.5, has read and write permissions (again we've omitted "-ro"), and access rights for users with UID 501 ("Memphis", in my case) are used (-mapall=501).
Note: As already mentioned, the authentication to the NFS server is done through UIDs. For XBMC, this means that the UID which the XBMC process is running under is given to the NFS server. To find out your current UID, just type "id" into a console:
   Mac:~ [your_user_name]$ id
You should see something that begins like this:
   uid=501(your_user_name)
In this example, my UID is 501. If you are going to be connecting to your NFS shared folder from XBMC on iOS, keep in mind that on iOS XBMC runs as the user "mobile", which should have UID 501 also.
  • The path "/nfs/xbmcuser" can be accessed from all computers (no ip given), readwrite (no "-ro") and the access rights for the UID which is connecting to the NFS server are used ("-mapall" removed).

The UIDs which are used to connect to the NFS server or which are specified with "-mapall" have to exist on the NFS server. Otherwise the filesystem permission can't be set.

Remember - access rights are these you give in the filesystem. Each change on the exports config file needs a restart of the nfs server! Just issue "sudo nfsd restart" for this.

3. Once you've configured and saved your /etc/exports file, the NFS server can be started either by rebooting or by executing the following command: 

 $ sudo nfsd start

NFS sharing from Linux

Introduction

NFS sharing has been built into linux kernel for a long time. For basic setup guidelines, please take a look at the following link:
Note! This article assumes some basic knowledge of the Linux/UNIX/BSD operating-system interface and environment.


Configuring NFS sharing from Linux for use with XBMC

The configuration of the NFS server takes place in the config file "/etc/exports". As already mentioned, the authentication to the NFS server is done through UIDs. For XBMC, this means the UID that the XBMC process is running under is used to authenticate on the NFS server. To find out what UID XBMC is using, just type "id" into a console: 

 penix:~ [your_user_name]$ id
 uid=501(your_user_name)

In this example, my UID is 501. For iOS devices, keep in mind that XBMC is running as the user "mobile", whose UID should also be 501.

A basic configuration for exporting a path with NFS looks like this: 

 /nfs/export <ip or iprange which is allowed to connect>(rw,all_squash,insecure)

The important options here for use with XBMC are the "ip or iprange" and the "insecure" options. The "insecure" option is needed because we want to be able to run XBMC without root privileges. If the insecure option is not enabled, only the root user (uid 0) will have access to the nfs share. The "ip or iprange" specifies which hosts on the network will be allowed to access the exported NFS share.

By changing some of the options of that line, we can use any of three different approaches for getting the access rights configured as we want:

1. The option all_squash (most insecure) - all UIDs connected to the NFS server are mapped to UID 65534 (user nobody)

  • In this case all files which shall be accessed on the NFS exported path should have the correct rights for the user "nobody".

2. Using the option "all_squash" in conjunction with the option "anonuid" and "anongid"

  • By adding the options "anonuid=501" and "anongid=501" all accesses would be mapped to the user with UID 501 (user "mobile" on iOS or user "memphis" in my example above)

3. Removing the "all_squash" option the accesses will be done with the UID given from the user which is running XBMC

  • So if XBMC is started with username foobar (which has UID 1000) all accesses to the NFS export path will be made with UID 1000.


Examples for exported paths 

 /nfs/allread                *(r,all_squash,insecure)
 /nfs/allwrite               192.168.1.0/24(rw,all_squash,insecure)
 /nfs/writeAsMemphis         192.168.1.5(rw,all_squash,insecure,anonuid=501,anongid=501)
 /nfs/xbmcuser               *(rw,insecure)

The path "/nfs/allread" can be accessed from all computers ("*"), readonly ("r") and access rights for user nobody are used ("all_squash").

The path "/nfs/allwrite" can be accessed from all computers on the subnet 192.168.1.0/255.255.255.0, readwrite ("rw") and access rights for user nobody are used ("all_squash"). Remeber that "rw" doesn't mean automatically that you can write. The user "nobody" has to have write access to the exported path too for finally allow writing.

The path "/nfs/writeAsMemphis" can be accessed from the computer with the IP 192.168.1.5, readwrite ("rw"), and access rights for user with UID 501 (e.x. memphis in my case) are used ("all_squash,anonuid=501,anongid=501").

The path "/nfs/xbmcuser" can be accessed from all computers ("*"), readwrite ("rw") and the access rights for the UID which is connecting to the NFS server are used ("all_squash" removed).

The UIDs which are used to connect to the NFS server or which are specified with "anonuid" and "anongid" have to exist on the NFS server. Otherwise the filesystem permission can't be set.

Remember - access rights are these you give in the filesystem. Remember - access rights are these you give in the filesystem. After each change to the exports config file issue "sudo exportfs -ra"!

NFS sharing from FreeNAS

The information in the Linux section above also applies for *BSD based systems (such as FreeBSD). This section addresses some specific issues to bear in mind if you are using FreeNAS 7.x (aka. legacy) installations.

Setup your NFS shares as normal. Remember: don't create shares inside other shares. The following would be illegal... 

 /mnt/disk                   -alldirs,quiet -mapall=root -network 192.168.1.0 -mask 255.255.255.0
 /mnt/disk/folder            -alldirs,quiet -mapall=root -network 192.168.1.0 -mask 255.255.255.0

...because the "/mnt/disk/folder" directory is already shared by "/mnt/disk". If you remember to set the setting "All dirs" when creating your NFS shares, the flag "-alldirs" will be set. This flag allows you to mount any subdirectory of your share just as if it was a share itself. Said another way: It's not necessary to share "/mnt/disk/folder" because you can mount it through the "/mnt/disk" share.

After having set up a standard NFS share on your FreeNAS box, you need to add a few variables to rc.conf on FreeNAS. This is done by going into System > Advanced > rc.conf . Here you need to add the following: 

 Variable                     Value              Comment
 mountd_flags                 -n                 Allow non-root mount requests to be served. 	  
 nfs_reserved_port_only       NO                 Allow for insecure ports to be used by NFS.	  
 nfs_server_flags             -u -t -n 4         Serve UDP and TCP with 4 servers.

After this, apply your changes and reboot FreeNAS. You should now be able to mount your NFS shares, as well as any subdirectory of those shares. Note: It has been reported the NFS client included with XBMC is unable to browse sub-directories on NFS shares using this method. See this thread for more information.

NFS sharing from commercial NAS systems such as Synology or QNAP

Each NAS manufacturer, if it allows you to share folders via NFS on its NAS systems, does so in its own way. Often this will involve setup via the NAS's control panel or administrator interface. You can also connect to many NAS systems via ssh and directly edit files in order to set up and configure NFS (consult your NAS manual to see if this is possible/desirable/necessary).

Troubleshooting NFS on a commercial NAS with XBMC
One of the most common problems with setting up NFS on a commercial NAS is due to the fact that many commercial NAS's come with the "insecure" option disabled for NFS shares. If you are having trouble connecting to your NFS shares on your NAS from XBMC, make sure your NFS shares have the "insecure" option enabled.
Retrieved from "https://kodi.wiki/index.php?title=NFS&oldid=27390"