X-Git-Url: https://git.decadent.org.uk/gitweb/?p=nfs-utils.git;a=blobdiff_plain;f=debian%2FREADME.Debian.nfsv4;h=453e2f847bf71ad32de9431e0a7524ffd1d258cc;hp=7e1aeafce4f1a6642360069cb2e8ad1439634d8c;hb=e56040cff413b83957f87d170cb1dd2b6b61b0bf;hpb=22e8fbbc869085df2a050159bf559f8e97b670b1 diff --git a/debian/README.Debian.nfsv4 b/debian/README.Debian.nfsv4 index 7e1aeaf..453e2f8 100644 --- a/debian/README.Debian.nfsv4 +++ b/debian/README.Debian.nfsv4 @@ -4,20 +4,29 @@ NFSv4 in Debian NFSv4 support in Debian is rather new, and not fully supported yet. If you want to experiment, make sure you have: - - a recent 2.6 kernel on both client and server; newer is better. You might even - want to use CITI's patch set from http://www.citi.umich.edu/projects/nfsv4/linux/ . + - a recent 2.6 kernel on both client and server; newer is better. You might + even want to use CITI's patch set from + http://www.citi.umich.edu/projects/nfsv4/linux/ on the server, and/or Trond + Myklebust's patch set from http://client.linux-nfs.org/ . - a recent enough version of nfs-utils on both client and server (you probably have on at least one of them, since you're reading this file!). - enabled idmapd on both sides (see /etc/default/nfs-common). + - The following lines in /etc/services on the client (if not, you will receive + the message "broken /etc/services" when starting rpc.gssd; this will usually + only happen if you upgrade netbase without letting it replace /etc/services + with the new version): + + nfs 2049/tcp # Network File System + nfs 2049/udp # Network File System The export structure might be a bit confusing if you're already familiar with -NFSv2 or NFSv3. The biggest difference is that you will need to export an explicit -root of your pseudofilesystem, like this /etc/exports fragment: +NFSv2 or NFSv3. The biggest difference is that you will need to export an +explicit root of your pseudofilesystem, like this /etc/exports fragment: /nfs4 hostname(rw,sync,fsid=0,crossmnt) -(It doesn't need to be named "nfs4".) Then you can mount other volumes under that, -like: +(It doesn't need to be named "nfs4".) Then you can mount other volumes under +that, like: /nfs4/music hostname(rw,sync) /nfs4/movies hostname(rw,sync) @@ -26,8 +35,8 @@ Then your client can mount shares like this: mount -t nfs4 server:/music /mnt/music -Since you might not have everything under one root, you might want /nfs4/* on the -server to be bind mounts, ie.: +Since you might not have everything under one root, you might want /nfs4/* on +the server to be bind mounts, ie.: mount --bind /srv/music /nfs4/music @@ -45,10 +54,18 @@ instead of a hostname to get Kerberos-based authentication instead. For this, you will need an "nfs/hostname@REALM" entry in /etc/krb5.keytab, as well as rpc.gssd running on both client and rpc.svcgssd on the server (enable them manually in /etc/default/nfs-common and /etc/default/nfs-kernel-server if the -autodetection fails). +autodetection fails). On the client, you will need to add "-o sec=krb5" to +the mount call. + +If you use "gss/krb5i" (and correspondingly "-o sec=krb5i" on the client), you +will also get integrity (ie. authentication), and with "gss/krb5p", you'll also +get privacy (ie. encryption). Make sure your kernel supports this; not all +kernels do. -If you use "gss/krb5i", you will also get integrity (ie. authentication), and -with "gss/krb5p", you'll also get privacy (ie. encryption). Make sure your -kernel supports this; not all kernels do. +If you receive messages on the server complaining about "client ID already in +use" when mounting from more than one client, check that you have at least +mount version 2.12r-14. Also, connecting from behind different NATs could cause +this kind of issue currently, as two or more clients would believe they had the +same IP. - -- Steinar H. Gunderson , Wed, 06 Sep 2006 00:32:38 +0200 + -- Steinar H. Gunderson , Wed, 11 Oct 2006 15:18:03 +0200