NFS
Introduction
- Network Filesystem, 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 advantages over other network sharing options:
- 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, removing the need of saving username and password 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, it will allow your network shares to be seen and accessed by not only XBMC, but also any other machine on your network.
- For all examples below, NFS shares should be added to XBMC with 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 (as configured from the HowTo's below). For more info on network sources, see Types_of_Media_Sources.
Network Filesystem Sharing (on Windows)
- For serving and sharing files with NFS from Windows 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 a Windows client
- Accessing an NFS share natively from within XBMC for Windows is not possible right now. The porting of 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.
Network Filesystem Sharing (on Mac OS X)
Introduction
- NFS Sharing, is build into Mac OSX (OS 10.5 and later). For basic setup guidelines please take a look at the following links:
- Note! This article assumes some basic knowledge of the UNIX/BSD operating-system interface and environment.
Configuring NFS Sharing for using with XBMC (leopard and snow leopard)
For allowing non root users to connect to the NFS server the file "/System/Library/LaunchDaemons/com.apple.nfsd.plist" has to be edited. Add the option "-N" to the startup parameters. Otherwise XBMC can only access the NFS server when run as root.
<array> <string>/sbin/nfsd</string> <string>-N</string> </array>
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. So for XBMC this means that the UID which the XBMC process is running under is given to the NFS server. For knowing the UID just type "id" into a console:
penix:~ memphis$ id uid=501(memphis)
So my UID is 501. For iOS keep in mind that the user XBMC is running as is the user "mobile" which should have UID 501 also.
A basic configuration for exporting one PATH with NFS is looking 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 for exported pathes
/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
The path "/nfs/allread" can be accessed from all computers (no ip given), readonly ("-ro") and access rights for user 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, readwrite (no "-ro") and access rights for user nobody are used ("-mapall=nobody").
The path "/nfs/writeAsMemphis" can be accessed from the computer with the IP 192.168.1.5, readwrite (no "-ro"), and access rights for user with UID 501 (e.x. memphis in my case) are used (-mapall=501).
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.
The server can be started by doing:
$ sudo nfsd start
Network Filesystem Sharing (on Linux)
Introduction
- NFS Sharing, is build into linux kernel since long time ago. 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 for using 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. So for XBMC this means that the UID which the XBMC process is running under is given to the NFS server. For knowing the UID just type "id" into a console:
penix:~ memphis$ id uid=501(memphis)
So my UID is 501. For iOS keep in mind that the user XBMC is running as is the user "mobile" which should have UID 501 also.
A basic configuration for exporting one PATH with NFS is looking like this:
/nfs/export <ip or iprange which is allowed to connect>(rw,all_squash,insecure)
The important options here for usage with XBMC are the "ip or iprange" and the "insecure" option. The "insecure" option is needed because we want to be able to run XBMC without root privileges. When using secure only the root user (uid 0) may have access to the nfs share. The "ip or iprange" specifys from wich hosts in the network the access to the NFS export is allowed.
By changing some of the options of that line we can realise 3 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"!
Network Filesystem Sharing (on FreeNAS)
This also holds true for *BSD based systems (such as FreeBSD). This section is specifically made for helping out 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 makes sure you can mount any subdirectory of your share, just as if it was a share itself. Said in another way: It's not necessary to share "/mnt/disk/folder" because you can mount it through the "/mnt/disk" share.
Right, after having setup 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 nfsclient included with XBMC is unable to browse sub-directories on NFS shares using this method. See this thread.
Network Filesystem Sharing (on 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.