How to install NFS under OpenSlug

This HowTo might be a little bit chaotic and incomplete. It took me a little bit of tweaking to get things running, and some steps might not be needed or out of order. If you use this HowTo and find flaws please correct!

The following steps are needed

1. Make sure that your slug is up to date (ipkg update; ipkg upgrade).
2. Install nfsd (ipkg install kernel-module-nfsd)
3. Install nfs-utils (ipkg install nfs-utils). You might also want to install nfs-utils-doc too.
4. Install module-init-tools (ipkg install module-init-tools). This will give you a better working modprobe.
5. create a file /etc/exports. The format of this file is
   <directory to share> <computer to share to>(options).
   E.g.:
   
   /usr/public 192.168.1.4(rw)
   
   where 192.168.1.4 is the PC to which you want to export the directory.
6. either restart the box, or execute the command depmod -a
7. start the daemons by sh /etc/init.d/nfsserver start

On the PC with IP address 192.168.1.4 you can just say mount 192.168.1.77:/usr/public /mnt assuming your slug is on 192.168.1.77. You can of course also use the name of the slug instead of the IP address.

Note: i wasn't able to install nfs, because update.d-rc was missing. If it happend, try "export PATH=$PATH:/user/sbin". If it works, add this path in your /etc/profile

Some additional options for the /etc/exports file:
The example above is a fairly secure way to export the /usr/public directory - it permits only the computer at IP address 192.168.1.4 to mount the /usr/public directory. In cases where multiple computers wish to mount the directory, or if you are using DHCP where you can't guarantee exactly which IP address a computer will be using from day-to-day, a slightly different syntax can be used to specify a range of accepted IP addresses. For example:

/usr/public 192.168.1.0/24(rw)

specifies that any IP address in the range 192.168.1.0 to 192.168.1.255 will be allowed. If you prefer the traditional netmask way of expressing this, this format:

/usr/public 192.168.1.0/255.255.255.0(rw)

is equivalent.

The (rw) option should be self-explanatory; it can be replaced by (ro) in order to ensure that other systems can only mount this exported directory for read access.

NFS and the super-user (root) have an interesting relationship, one which can trip up unsuspecting users. Specifically, there's no guarantee that the owner of the root account on an NFS client should have the same root privileges on the NFS server. In order to make sure that the client does not gain more privileges than it should, NFS maps the client's root user to the "nobody" user on the server. This behavior is generally regarded as a feature, but it may not be how you wish your network to operate. If you can say that the root user in your network is "trusted", then you can explicitly inform NFS that it is not to perform this mapping; i.e. the root account on the client is to have the full privileges accorded with the superuser on the mounted filesystem:

/usr/public 192.168.1.0/255.255.255.0(rw,no_root_squash)

Fine Print: a note on permissions with NFS in general. NFS uses the user numbers and group numbers associated with a process, not the textual user ids or textual group names. Basically this means that if you do not keep your passwd files in close syncronization, you can introduce a great deal of confusion into your network, if not an outright security problem. For example, assume user id "fred" is added on one system and assigned UID number 501, while on another system somewhere, user id "ethel" is added and is given the UID number 501 on that system. Since NFS uses only the user id, on NFS filesystem shared between these two systems fred and ethel have the same privileges -- the two users are one-and-the-same from the NFS filesystem's point-of-view. This is easily avoided by making sure that the UID numbers and GID numbers in the passwd files are consistent across the various system in the network.

Currently with nfs-utils version 1.0.6-r2, these additional steps must be taken:

• mkdir /var/lib/nfs
• touch /var/lib/rmtab
• touch /etc/default/nfsd (actually this step might not be needed)

(Not required as of ver 1.0.6-r3)

To get NFS to automatically start at boot time: (Not required as of ver 1.0.6-r3) Run the command "update-rc.d nfsserver defaults" which will create the scripts to start it in levels 2-5 and stop it in 0, 1 and 6. Some documentation on update-rc.d is here http://wiki.linuxquestions.org/wiki/Update-rc.d

Problem with NFSD
If you have the problem when you type /etc/init.d/nfsserver start and the following line is in the log :
Sep 30 15:49:07 (none) daemon.err nfsd[2030]: nfssvc: No such device
You must launch the command :
depmod -a

Hanging on Startup
If /etc/init.d/nfsserver start is hanging at "starting 8 nfsd kernel threads:" every time, it helped for me to reinstall portmap (I know it is already installed, but something apparently went wrong):
ipkg -force-reinstall install portmap
After that, the NFS Server started flawlessly for me.

Portmap tip #2
If you get a message like this in dmesg when (re)starting portmap and nfs: RPC: failed to contact portmap (errno -5). then install portmap-utils and restart portmap/nfs again.