view · edit · print · history

uNSLUng on the NSLU2 supports NFS via user installed packages.

If you are going to use NFS and you aren't already familiar on how to use NFS via Linux or other hosts, then you should probably spend time Googling etc. Familiarity with Linux networking, processes, daemons etc is assumed.

*** This not package is not recommended - use nfs-utils instead. This is a user space daemon, nfs-utils uses kernel space, and hence should be faster. ***

If you are still interested, you can install "native" NFS version 3 support into your uNSLUng NSLU2 via the following process:

  1. telnet / ssh to your NSLU2.
  2. Create an /share/hdd/conf/exports file and link into the correct place. The format of the exports file is below.
    1. vi /share/hdd/conf/exports
      Type in your exports and save. Or use your favourite editor.
    2. ln -s /share/hdd/conf/exports /etc/exports
  3. Install a portmapper and the UNFS daemon:
    1. ipkg install portmap
    2. ipkg install unfs3
  4. Check that the unfds and portmap daemons are running.
    1. ps -ef | grep unfsd | grep -v grep
      1118 bin 1216 S /opt/sbin/portmap
    2. ps -ef | grep portmap | grep -v grep
      1197 root 5888 S /opt/sbin/unfsd

      (I had to edit /etc/services and change nfsd to unfsd)
  5. From your client machine see if NFS is working correctly (use your NSLU IP address if it isn't the default):
    root@ttyp2[knoppix]$ showmount -e
    Export list for

    If you get a
    mount clntudp_create: RPC: Program not registered error
    then your unfsd daemon isn't running.
    If you get a
    mount clntudp_create: RPC: Port mapper failure - RPC: Unable to receive
    then your portmap daemon isn't running or you've used the wrong IP address in your showmount command.
  6. Create a mount point on your client if a suitable one doesn't already exist:
    root@ttyp2[knoppix]# mkdir -p /mnt/nslu2
  7. Mount your NSLU2. Notice the mount options.
    root@ttyp2[knoppix]# mount -o vers=3,tcp,nolock,intr /mnt/nslu2

    The mount options used are:
    vers=3 <-- Use NFS version 3. [required]
    tcp <-- Use TCP networking. [required]
    nolock <-- Do not use NFS locking. [required]
    intr <-- Allow requests to be aborted [optional, recommended]

    Your NFS client may already use some of these options by default. It never hurts to be sure though.

    If you forget to use the nolock option then your mount request may completely hang without the mount being performed. This is because your client may expect the NLM lock manager to be running and will wait for a response from it.

Other tips:

  1. When changing your exports file use the following to tell unfsd to reload it's database:
    # /opt/etc/init.d/S56unfsd

    This also starts the daemon if (for some reason) it isn't already running. Doing this may be disruptive to transfers that are underway though NFS is generally designed to cope.
  2. To start / restart the portmap service use
    # /opt/etc/init.d/S55portmap

NOTE by JamesCC?: I had a problem with groups using Unfs3. I could NOT read files owned by someone else (in my group), despite the file being group readable. Interestingly if I su to the user owning the file read the file and returned, I could then read the file. nfs-utils (alternative) doesn't seem to have this problem?

Exports file format:

The exports file contains 1 or more of the following lines.

  {path to export} [[client][(client option, ...)] ...]

The {path to export} needs to be a valid path on your NSLU2. For example /share/hdd/data/public is a good place to start. If you are the only person with network access to your NSLU2 then you may use a simple / and your entire NSLU2 will be available. Use "quotes" around your path if it has "s p a c e s" in it.

If [client] is ommited then all clients are allowed access to mount. Use [client] to restrict mount access. Remember that NFSv3? uses "trusted hosts" rather than trusted users so the more clients, the more risk.

You can use either individual IP addresses, assuming you don't have DNS/hosts enabled, if you do you can use hostnames, or you can use subnet masking. e.g.              <--- this means just this one IP address  <--- all IP addresses on the 192.168.1.x subnet

Additionally, use the [client options] section to further control access.

Common options include:

  ro             <--- Only Read-only access allowed. This is the Default.
  rw             <--- Read-write access. 
  root_squash    <--- If a UID 0 is passed from the client, remap to nobody (65534). Default.
  no_root_squash <--- Allow a UID 0 to be treated as the user root.
  all_squash     <--- All users are treaded as UID nobody (65534).

Example exports file:


  /share/hdd/data/public (rw,no_root_squash)
  "/share/hdd/data/my private stuff",no_root_squash)

The first line allows the public folder to be used by anyone anywhere anyhow. Root is allowed, as is writing.

The second shares "my private stuff" just for a single host. Root is allowed, as is writing. Quotes are needed because of the spaces.

The third line is an export that is for the 192.168.1.x subnet only and is read-only because of the default options.

The forth line allows read-write access and read-only access. All other clients are denied access. Root is squashed in both cases because it is the default.

view · edit · print · history · Last edited by JamesCC.
Based on work by tman, chrisc, TheSnark, and uSURPER.
Originally by uSURPER.
Page last modified on November 15, 2006, at 05:33 PM