debian/README.Debian.nfsv4

   1 NFSv4 in Debian
   2 ===============
   3
   4 NFSv4 support in Debian is rather new, and not fully supported yet. If you want
   5 to experiment, make sure you have:
   6
   7  - a recent 2.6 kernel on both client and server; newer is better. You might
   8    even want to use CITI's patch set from
   9    http://www.citi.umich.edu/projects/nfsv4/linux/ on the server, and/or Trond
  10    Myklebust's patch set from http://client.linux-nfs.org/ .
  11  - a recent enough version of nfs-utils on both client and server (you probably
  12    have on at least one of them, since you're reading this file!).
  13  - enabled idmapd on both sides (see /etc/default/nfs-common).
  14  - The following lines in /etc/services on the client (if not, you will receive
  15    the message "broken /etc/services" when starting rpc.gssd; this will usually
  16    only happen if you upgrade netbase without letting it replace /etc/services
  17    with the new version):
  18
  19    nfs          2049/tcp                        # Network File System
  20    nfs          2049/udp                        # Network File System
  21
  22 The export structure might be a bit confusing if you're already familiar with
  23 NFSv2 or NFSv3. The biggest difference is that you will need to export an
  24 explicit root of your pseudofilesystem, like this /etc/exports fragment:
  25
  26   /nfs4                   hostname(rw,sync,fsid=0,crossmnt)
  27
  28 (It doesn't need to be named "nfs4".) Then you can mount other volumes under
  29 that, like:
  30
  31   /nfs4/music             hostname(rw,sync)
  32   /nfs4/movies            hostname(rw,sync)
  33
  34 Then your client can mount shares like this:
  35
  36   mount -t nfs4 server:/music /mnt/music
  37
  38 Since you might not have everything under one root, you might want /nfs4/* on
  39 the server to be bind mounts, ie.:
  40
  41   mount --bind /srv/music /nfs4/music
  42
  43 or in /etc/fstab:
  44
  45   /srv/music /nfs4/music none bind 0 0
  46
  47 Note that this special export structure might be handled transparently by
  48 rpc.mountd at some time in the future, in which case you will probably get the
  49 traditional (NFSv3-style) behaviour if and only if you have no share with
  50 fsid=0.
  51
  52 If you do not wish to use host-based authentication, you can specify "gss/krb5"
  53 instead of a hostname to get Kerberos-based authentication instead. For this,
  54 you will need an "nfs/hostname@REALM" entry in /etc/krb5.keytab, as well as
  55 rpc.gssd running on both client and rpc.svcgssd on the server (enable them
  56 manually in /etc/default/nfs-common and /etc/default/nfs-kernel-server if the
  57 autodetection fails). On the client, you will need to add "-o sec=krb5" to
  58 the mount call.
  59
  60 If you use "gss/krb5i" (and correspondingly "-o sec=krb5i" on the client), you
  61 will also get integrity (ie. authentication), and with "gss/krb5p", you'll also
  62 get privacy (ie. encryption). Make sure your kernel supports this; not all
  63 kernels do.
  64
  65 If you receive messages on the server complaining about "client ID already in
  66 use" when mounting from more than one client, check that you have at least
  67 mount version 2.12r-14. Also, connecting from behind different NATs could cause
  68 this kind of issue currently, as two or more clients would believe they had the
  69 same IP.
  70
  71  -- Steinar H. Gunderson <sesse@debian.org>, Wed, 11 Oct 2006 15:18:03 +0200