“UbuntuHelp:NFSv4Howto”的版本间的差异
来自Ubuntu中文
小 |
小 |
||
第45行: | 第45行: | ||
* Be aware of the following points: | * Be aware of the following points: | ||
* Setting the crossmnt option on the main psuedo mountpoint has the same effect as setting nohide on the sub-exports: It allows the client to map the sub-exports within the psuedo filesystem. These two options are mutually exclusive. | * Setting the crossmnt option on the main psuedo mountpoint has the same effect as setting nohide on the sub-exports: It allows the client to map the sub-exports within the psuedo filesystem. These two options are mutually exclusive. | ||
− | * Note that when locking down which clients can map an export by setting the IP and subnet mask, 255.255.255.0 does not work. Either do not set any subnet or use /24 as shown. Can someone please provide a reason for this behaviour? | + | * Note that when locking down which clients can map an export by setting the IP and subnet mask, 255.255.255.0 does not work. Either do not set any subnet or use /24 as shown. Can someone please provide a reason for this behaviour? /* Subnet mask marks which part of IP address must be evaluated. Subnet mask for single client's IP must be /32 or 255.255.255.255, that is, full IP address must be evaluated. Try clients IP address with subnet mask /32. Please update this article, someone who can check this! */ |
* Restart the service | * Restart the service | ||
<pre><nowiki> | <pre><nowiki> | ||
第52行: | 第52行: | ||
* On the client we can mount the complete export tree with one command: | * On the client we can mount the complete export tree with one command: | ||
<pre><nowiki> | <pre><nowiki> | ||
− | # mount -t nfs4 -o proto=tcp,port=2049 nfs-server:/ /mnt</nowiki></pre> | + | # mount -t nfs4 -o proto=tcp,port=2049 nfs-server:/export /mnt</nowiki></pre> |
* We can also mount an exported ''subtree'' with: | * We can also mount an exported ''subtree'' with: | ||
<pre><nowiki> | <pre><nowiki> | ||
− | # mount -t nfs4 -o proto=tcp,port=2049 nfs-server:/users /home/users</nowiki></pre> | + | # mount -t nfs4 -o proto=tcp,port=2049 nfs-server:/export/users /home/users</nowiki></pre> |
* To save us from retyping this after every reboot we add the following | * To save us from retyping this after every reboot we add the following | ||
line to <code><nowiki>/etc/fstab</nowiki></code>: | line to <code><nowiki>/etc/fstab</nowiki></code>: | ||
第64行: | 第64行: | ||
They do not work. Can someone please help investigating? Following this guide will result in UID/GID on the export being generic despite having same UID on client and server. Mounting same shar on NFSv3 works correctly with regards to UID/GID. Does this need Kerberos to work fully? | They do not work. Can someone please help investigating? Following this guide will result in UID/GID on the export being generic despite having same UID on client and server. Mounting same shar on NFSv3 works correctly with regards to UID/GID. Does this need Kerberos to work fully? | ||
This is a possibly related bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=500778 | This is a possibly related bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=500778 | ||
+ | Not clear what is meant by UID/GID on the export being generic. This guide does not explicitly state that idmapd must also run on the client side, i.e. <code><nowiki>/etc/default/nfs-common</nowiki></code> needs the same settings as described in the server section. If idmapd is running the UID/GID are mapped correctly. Check with <code><nowiki>ps ax|grep rpc</nowiki></code> that <code><nowiki>rpc.idmapd</nowiki></code> is running. | ||
If all directory listings show just "nobody" and "nogroup" instead of real user and group names, then you might want to '''check the Domain parameter''' set in <code><nowiki>/etc/idmapd.conf</nowiki></code>. NFSv4 client and server should be in the same domain. Other operating systems might derive the NFSv4 domain name from the domain name mentioned in /etc/resolv.conf (e.g. Solaris 10). | If all directory listings show just "nobody" and "nogroup" instead of real user and group names, then you might want to '''check the Domain parameter''' set in <code><nowiki>/etc/idmapd.conf</nowiki></code>. NFSv4 client and server should be in the same domain. Other operating systems might derive the NFSv4 domain name from the domain name mentioned in /etc/resolv.conf (e.g. Solaris 10). | ||
* If you have a slow network connection and are not establishing mount at reboot, you can change the line in <code><nowiki>etc/fstab</nowiki></code>: | * If you have a slow network connection and are not establishing mount at reboot, you can change the line in <code><nowiki>etc/fstab</nowiki></code>: | ||
第77行: | 第78行: | ||
All uids will be mapped to the nobody uid. | All uids will be mapped to the nobody uid. | ||
mount: unknown filesystem type 'nfs4'</nowiki></pre> | mount: unknown filesystem type 'nfs4'</nowiki></pre> | ||
− | then you need to set in <code><nowiki>/etc/default/nfs-common</nowiki></code>: | + | (all directories and files on the client are owned by uid/gid 4294967294:4294967294) then you need to set in <code><nowiki>/etc/default/nfs-common</nowiki></code>: |
<pre><nowiki> | <pre><nowiki> | ||
NEED_IDMAPD=yes</nowiki></pre> | NEED_IDMAPD=yes</nowiki></pre> | ||
第84行: | 第85行: | ||
# /etc/init.d/nfs-common restart</nowiki></pre> | # /etc/init.d/nfs-common restart</nowiki></pre> | ||
The "unknown Filesystem" Error will disappear as well. | The "unknown Filesystem" Error will disappear as well. | ||
+ | ==== NFSv4 and Autofs ==== | ||
+ | Automount (or autofs) can be used in combination with NFSv4. Details on the configuration of autofs can be found in the [[UbuntuHelp:Autofs|AutofsHowto]]. The configuration is identical to NFSv2 and NFSv3 except that you have to specify <code><nowiki>-fstype=nfs4</nowiki></code> as option. Automount supports NFSv4's feature to mount all file systems exported by server at once. The exports are then treated as an entity, i.e. they are "all" mounted when you step into "one" directory on the NFS server's file systems. When auto-mounting each file system separately the behavior is slightly different. In that case you would have to step into "each" file system to make it show up on the NFS client. | ||
+ | === NFSv4 and NFSv3 simultaneously === | ||
+ | NFSv4 and NFSv3 can be used simultaneously on a NFS server as well as on a NFS client. You have to setup NFSv3 on your NFS server (see [[UbuntuHelp:SettingUpNFSHowTo|SettingUpNFSHowTo]]). You can then export a file system with NFSv4 and NFSv3 simultaneously. Just put the appropriate export statements into <code><nowiki>/etc/exports</nowiki></code> and you are done. You might want to do this when you have NFS clients that don't support NFSv4, e.g. Mac OS X and Windows clients. But don't forget about the security risks of NFS with clients that can not be trusted. | ||
=== NFSv4 with Kerberos === | === NFSv4 with Kerberos === | ||
When using NFS without kerberos the security of all data in the NFS share depends on the integrity of all clients and the security of the network connections. | When using NFS without kerberos the security of all data in the NFS share depends on the integrity of all clients and the security of the network connections. | ||
第95行: | 第100行: | ||
... this means you need to type echo "hello" on the KDC. | ... this means you need to type echo "hello" on the KDC. | ||
Please note that you can now (with Ubuntu 8.04 and later) use any encryption type you want, there is no more need to extract only ''des-cbc-crc'', as most sites suggest. See [http://mailman.mit.edu/pipermail/kerberos/2008-May/013698.html this mailinglist message]. | Please note that you can now (with Ubuntu 8.04 and later) use any encryption type you want, there is no more need to extract only ''des-cbc-crc'', as most sites suggest. See [http://mailman.mit.edu/pipermail/kerberos/2008-May/013698.html this mailinglist message]. | ||
+ | Please also note, that des-cbc-crc encryption is depreciated and, starting with Ubuntu 10.04, is no longer supported by default in the Kerberos libraries. For nfs4 to work, you need to add <code><nowiki>allow_weak_crypto = true</nowiki></code> to <code><nowiki>/etc/krb5.conf</nowiki></code> | ||
===== MIT ===== | ===== MIT ===== | ||
* On the nfs-server and nfs-client you need at least the ''krb5-user'' | * On the nfs-server and nfs-client you need at least the ''krb5-user'' |
2010年5月19日 (三) 23:44的最新版本
![]() |
点击翻译: |
English |
请不要直接编辑翻译本页,本页将定期与来源同步。 |
<<Include(Tag/NeedsExpansion)>> <<Include(Tag/StyleCleanup)>>
目录
Installation
The required packages are different depending on if the system is a client or a server. In this Howto, the server is the host that has the files you want to share and the client is the host that will be mounting the NFS share.
- NFSv4 client
# apt-get install nfs-common
- NFSv4 server
# apt-get install nfs-kernel-server
After you finish installing nfs-kernel-server, you might see failure to start nfs-kernel-server due to missing entries in /etc/exports. Remember to restart the service when you finish configuring.
NFSv4 without Kerberos
NFSv4 Server
NFSv4 exports exist in a single pseudo filesystem, where the
real directories are mounted with the --bind
option. Here is some additional information
regarding this fact.
- Let's say we want to export our users' home directories in
/home/users
. First
we create the export filesystem:
# mkdir /export # mkdir /export/users
and mount the real users directory with:
# mount --bind /home/users /export/users
To save us from retyping this after every reboot we add the following
line to /etc/fstab
/home/users /export/users none bind 0 0
- In
/etc/default/nfs-kernel-server
we set:
NEED_SVCGSSD=no # no is default
because we are not activating NFSv4 security this time.
- In
/etc/default/nfs-common
we set:
NEED_IDMAPD=yes NEED_GSSD=no # no is default
- To export our directories to a local network 192.198.1.0/24
we add the following two lines to /etc/exports
/export 192.168.1.0/24(rw,fsid=0,insecure,no_subtree_check,async) /export/users 192.168.1.0/24(rw,nohide,insecure,no_subtree_check,async)
- Be aware of the following points:
- Setting the crossmnt option on the main psuedo mountpoint has the same effect as setting nohide on the sub-exports: It allows the client to map the sub-exports within the psuedo filesystem. These two options are mutually exclusive.
- Note that when locking down which clients can map an export by setting the IP and subnet mask, 255.255.255.0 does not work. Either do not set any subnet or use /24 as shown. Can someone please provide a reason for this behaviour? /* Subnet mask marks which part of IP address must be evaluated. Subnet mask for single client's IP must be /32 or 255.255.255.255, that is, full IP address must be evaluated. Try clients IP address with subnet mask /32. Please update this article, someone who can check this! */
- Restart the service
# /etc/init.d/nfs-kernel-server restart
NFSv4 Client
- On the client we can mount the complete export tree with one command:
# mount -t nfs4 -o proto=tcp,port=2049 nfs-server:/export /mnt
- We can also mount an exported subtree with:
# mount -t nfs4 -o proto=tcp,port=2049 nfs-server:/export/users /home/users
- To save us from retyping this after every reboot we add the following
line to /etc/fstab
:
nfs-server:/ /mnt nfs4 _netdev,auto 0 0
where the auto
option mounts on startup and the _netdev
option waits until network devices are loaded.
- Note regarding UID/GID permissions on NFSv4 without Kerberos
They do not work. Can someone please help investigating? Following this guide will result in UID/GID on the export being generic despite having same UID on client and server. Mounting same shar on NFSv3 works correctly with regards to UID/GID. Does this need Kerberos to work fully?
This is a possibly related bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=500778
Not clear what is meant by UID/GID on the export being generic. This guide does not explicitly state that idmapd must also run on the client side, i.e. /etc/default/nfs-common
needs the same settings as described in the server section. If idmapd is running the UID/GID are mapped correctly. Check with ps ax|grep rpc
that rpc.idmapd
is running.
If all directory listings show just "nobody" and "nogroup" instead of real user and group names, then you might want to check the Domain parameter set in /etc/idmapd.conf
. NFSv4 client and server should be in the same domain. Other operating systems might derive the NFSv4 domain name from the domain name mentioned in /etc/resolv.conf (e.g. Solaris 10).
- If you have a slow network connection and are not establishing mount at reboot, you can change the line in
etc/fstab
:
nfs-server:/ /mnt nfs4 noauto 0 0
and execute this mount after a short pause once all devices are loaded. Add the following lines to /etc/rc.local
# sleep 5 # mount /mnt
- If you experience Problems like this:
Warning: rpc.idmapd appears not to be running. All uids will be mapped to the nobody uid. mount: unknown filesystem type 'nfs4'
(all directories and files on the client are owned by uid/gid 4294967294:4294967294) then you need to set in /etc/default/nfs-common
:
NEED_IDMAPD=yes
and restart nfs-common
# /etc/init.d/nfs-common restart
The "unknown Filesystem" Error will disappear as well.
NFSv4 and Autofs
Automount (or autofs) can be used in combination with NFSv4. Details on the configuration of autofs can be found in the AutofsHowto. The configuration is identical to NFSv2 and NFSv3 except that you have to specify -fstype=nfs4
as option. Automount supports NFSv4's feature to mount all file systems exported by server at once. The exports are then treated as an entity, i.e. they are "all" mounted when you step into "one" directory on the NFS server's file systems. When auto-mounting each file system separately the behavior is slightly different. In that case you would have to step into "each" file system to make it show up on the NFS client.
NFSv4 and NFSv3 simultaneously
NFSv4 and NFSv3 can be used simultaneously on a NFS server as well as on a NFS client. You have to setup NFSv3 on your NFS server (see SettingUpNFSHowTo). You can then export a file system with NFSv4 and NFSv3 simultaneously. Just put the appropriate export statements into /etc/exports
and you are done. You might want to do this when you have NFS clients that don't support NFSv4, e.g. Mac OS X and Windows clients. But don't forget about the security risks of NFS with clients that can not be trusted.
NFSv4 with Kerberos
When using NFS without kerberos the security of all data in the NFS share depends on the integrity of all clients and the security of the network connections. If you use kerberos the security doesn't depend on all client machines because the server gives access to users with a valid kerberos ticket only. The security isn't completely delegated to the client machines (unlike without kerberos). Therefor you need a principal in your kerberos realm for each user who want's to access the NFS share. See [1] on this topic. The section "Kerberos Linux Client" applies also to Ubuntu 8.04. You need a working Kerberos (MIT or Heimdal) KDC (Key Distribution Center) before continuing. NFS4 and Kerberos work fine with Ubuntu 8.04; they do not seem to work with the (much) older Ubuntu 6.06, or at least I couldn't get Heimdal to work correctly. Please note, that we have three different entities: the Kerberos-server; the NFS-server and the NFS-client. Your Kerberos-server (or KDC) and NFS-server could be the same machine, but they could also very well be separate entities. We will use separate "prompts" to distinguish, i.e. if you see
KDC$ echo "hello"
... this means you need to type echo "hello" on the KDC.
Please note that you can now (with Ubuntu 8.04 and later) use any encryption type you want, there is no more need to extract only des-cbc-crc, as most sites suggest. See this mailinglist message.
Please also note, that des-cbc-crc encryption is depreciated and, starting with Ubuntu 10.04, is no longer supported by default in the Kerberos libraries. For nfs4 to work, you need to add allow_weak_crypto = true
to /etc/krb5.conf
MIT
- On the nfs-server and nfs-client you need at least the krb5-user
and optional libpam-krb5 if you wish to authenticate against krb5.
# apt-get install krb5-user # apt-get install libpam-krb5
Heimdal
- On the nfs-server and nfs-client you need heimdal-clients
and optional libpam-krb5 if you wish to authenticate against krb5.
# apt-get install heimdal-clients # apt-get install libpam-krb5
- You need the gss kernel modules on nfs-servers and nfs-clients.
# modprobe rpcsec_gss_krb5
Add rpcsec_gss_krb5 to /etc/modules to have it loaded automatically. (I'm pretty sure they're loaded automatically though).
Create and distribute credentials
NFSv4 needs machine credentials for the server and every client, which wants to use the NFSv4 security features. Create the credentials for the nfs-server and all nfs-clients on the Kerberos KDC and distribute the extraced keys with scp to the destination You can make sure that only this entry has been created by executing "sudo klist -e -k /etc/krb5.keytab".
Create nfs/ principals
Authenticate as your admin user. You can do this from any machine in your kerberos-domain, as long as your kadmind is running; then add principals for your server and client machines. Replace "nfs-server.domain" with the fully qualified domain name of the machines. For example, if your server is called "snoopy" and your domain is "office.example.com", you would add a principal named "nfs/snoopy.office.example.com" for the server. Note: kadmin must be run with -l (locally) on the KDC if there is no kadmind. Please be aware of https://bugs.launchpad.net/ubuntu/+source/heimdal/+bug/309738/
Heimdal
$ kinit kadmin/admin $ kadmin add -r nfs/nfs-server.domain $ kadmin add -r nfs/nfs-client.domain
Now add these to the keytab-files on your NFS-server and client. Log in to your NFSserver (as root, because you will need to edit the /etc/krb5.keytab file) and initialize as Kerberos administrator. If your domain is fully kerberized, logging in as root will automatically give you the right access, in which case you don't need to use "kinit" anymore.
NFSserver# kinit kadmin/admin NFSserver# ktutil get nfs/nfs-server.domain
And add it to the client's keytab file:
NFSclient# kinit kadmin/admin NFSclient# ktutil get nfs/nfs-client.domain
MIT
$ kinit admin/admin $ kadmin -q "addprinc -randkey nfs/nfs-server.domain" $ kadmin -q "addprinc -randkey nfs/nfs-client.domain"
Now add these to the keytab-files on your NFS-server and client. Log in to your NFSserver (as root, because you will need to edit the /etc/krb5.keytab file) and initialize as Kerberos administrator.
NFSserver# kadmin -p admin/admin -q "ktadd nfs/nfs-server.domain"
And add it to the client's keytab file:
NFSclient# kadmin -p admin/admin -q "ktadd nfs/nfs-client.domain"
NFSv4 Server with Kerberos
- Check your machine credentials in /etc/krb5.keytab. Use "ktutil" (MIT) or "ktutil list" (Heimdal)
# ktutil ktutil: rkt /etc/krb5.keytab ktutil: list slot KVNO Principal ---- ---- --------------------------------------------------------------------- 1 2 nfs/nfs-server.domain@DOMAINHeimdal:
# ktutil list FILE:/etc/krb5.keytab: Vno Type Principal 6 des-cbc-md5 nfs/[email protected] 6 des-cbc-md4 nfs/[email protected] 6 des-cbc-crc nfs/[email protected] 6 aes256-cts-hmac-sha1-96 nfs/[email protected] 6 des3-cbc-sha1 nfs/[email protected] 6 arcfour-hmac-md5 nfs/[email protected]etcetera (I removed the krb4 entries as you probably won't use them anyway).
MIT extra information:
# sudo klist -e -k /etc/krb5.keytab Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 1 nfs/nfs-server.domain@DOMAIN (DES cbc mode with CRC-32)
- In
/etc/default/nfs-kernel-server
we set:
NEED_SVCGSSD=yes
- In
/etc/default/nfs-common
we set:
NEED_IDMAPD=yes
- To export our directories from the example above to a
local network 192.198.1.0/24 and addt
we add the following two lines to /etc/exports
/export 192.168.1.0/24(rw,fsid=0,insecure, \ no_subtree_check,async,anonuid=65534,anongid=65534) /export gss/krb5(rw,fsid=0,insecure, \ no_subtree_check,async,anonuid=65534,anongid=65534) /export/users 192.168.1.0/24(rw,nohide,insecure, \ no_subtree_check,async,anonuid=65534,anongid=65534) /export/users gss/krb5(rw,nohide,insecure, \ no_subtree_check,async,anonuid=65534,anongid=65534)
Please note that you can specify allowed hosts only in the any authentication flavor. gss/krb5 flavours are accessible from anywhere, if you do not use additional firewall rules. To export only with secure authentication flavors do not include a host(...) line in /etc/exports The gss/krb5 flavours are:
- krb5: users are authenticated
- krb5i: this includes krb5. Additionaly data integrity is provided.
- krb5p: this includes krb5i. Additionaly privacy is provided.
To display your exports enter:
# exportfs -v
NFSv4 Client with Kerberos
- Check your machine credentials in /etc/krb5.keytab
# ktutil ktutil: rkt /etc/krb5.keytab ktutil: list slot KVNO Principal ---- ---- --------------------------------------------------------------------- 1 2 nfs/nfs-client.domain@DOMAINHeimdal:
# ktutil list FILE:/etc/krb5.keytab: Vno Type Principal 6 des-cbc-md5 nfs/[email protected] 6 des-cbc-md4 nfs/[email protected] 6 des-cbc-crc nfs/[email protected] 6 aes256-cts-hmac-sha1-96 nfs/[email protected] 6 des3-cbc-sha1 nfs/[email protected] 6 arcfour-hmac-md5 nfs/[email protected]
- In
/etc/default/nfs-common
we set:
NEED_IDMAPD=yes NEED_GSSD=yes
- We can secure mount the complete export tree with:
# mount -t nfs4 -o sec=krb5 nfs-server:/ /mnt
- We can also secure mount an exported subtree with:
# mount -t nfs4 -o sec=krb5 nfs-server:/users /home/users
Troubleshooting
First, take care of proper logging - by default almost nothing is logged.
e.g. to enable 3rd level verbose logging for rpc.gssd, append the following to /etc/default/nfs-common
:
RPCGSSDOPTS="-vvv"
After restarting nfs-common (/etc/init.d/nfs-common restart
) check that the daemon has received new arguments:
ps xuwa | grep grep rpc.gssd root 9857 0.0 0.4 2496 1220 ? Ss 02:17 0:00 /usr/sbin/rpc.gssd -vvv
Then look for its log output in damon.log:
tail -f /var/log/daemon.log
For the server, you can e.g. raise rpc.svcgssd log level in /etc/default/nfs-kernel-server
:
RPCSVCGSSDOPTS="-vvv"
Browse the /etc/init.d/nfs-*
init scripts to see other variables that you can set in /etc/defaults
.
If using Kerberos, enable logging in /etc/krb5.conf
:
[logging] kdc = SYSLOG:INFO:DAEMON admin_server = SYSLOG:INFO:DAEMON default = SYSLOG:INFO:DAEMON
It's possible to increase verbosity in /etc/idmapd.conf
.
It can be useful to study the sources for better understandig error messages:
apt-get source nfs-common nfs-kernel-server libgssapi2-heimdal librpcsecgss3 libnfsidmap2