XBMC will be renamed to Kodi for v14. Read here for more details
Various pages on the wiki might contain old references to "XBMC", but will most often still apply to "Kodi". Find out how you can help here.

NFS

From Kodi
Revision as of 10:30, 24 June 2011 by Waldo22 (Talk)

Jump to: navigation, search

Contents

1 Introduction

Network Filesystem, (mostly called NFS), is a direct competitor to the SMB sharing. It benefits from low protocol overhead and unix like authentication via UIDs instead of usernam/password combinations. It is commonly found on all linux/unix distributions aswell as on Mac OS X and Solaris.
NFS sharing has many advantages over the other options, mainly:
  • It is already incorporated in UNIX like operating systems, eliminating the need for additional software and services to be installed on your PC
  • It allows for authentication by UID, removing the need of saving username and password in XBMC source xml files (but also makeing it weak for attacks - so NFS should be only used inside the own 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.

2 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.

3 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. So for makeing the "/nfs/allwrite" export path writeable to everyone the filesystem access rights have to be set for user nobody:

 chown -r nobody /nfs/allwrite

The server can be started by doing:

 $ sudo nfsd start

4 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 pathes

 /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. So for makeing the "/nfs/allwrite" export path writeable to everyone the filesystem access rights have to be set for user nobody:

 chown -r nobody /nfs/allwrite
Personal tools
Namespaces

Variants
Actions
Navigation
Wiki help
Toolbox