yum install nfs-utils -y
# 格式： # 作为共享的本地目录 主机A(权限) 主机B(权限) # fsid=0表示客户端挂载时将/data/share映射为/根目录 /data/share 192.168.1.111(rw,sync,fsid=0,no_root_squash) 192.168.1.112(rw,sync,fsid=0,no_root_squash)
chkconfig rpcbind on chkconfig nfs on service rpcbind start service nfs start
yum install nfs-utils -y
mount -t nfs4 -o rw,intr,hard,proto=tcp,noatime,nodev,noexec,nosuid 192.168.1.22:/ /data/web/wwwroot/upload/
Aug 25 16:19:13 localhost nfsidmap: nss_getpwnam: name 'root@localhost' does not map into domain 'localdomain' Aug 25 16:19:13 localhost nfsidmap: nss_name_to_gid: name 'root@localhost' does not map into domain 'localdomain'
idmapd errors about "localdomain", or chown failing on nfs4 mount, with "invalid argument"
NFSv4 handles user identities differently than NFSv3. In v3, an nfs client would simply pass a UID number in chown (and other requests) and the nfs server would accept that (even if the nfs server did not know of an account with that UID number). However, v4 was designed to pass identities in the form of @. To function correctly, that normally requires idmapd (id mapping daemon) to be active at client and server, and for each to consider themselves part of the same id mapping domain.
Chown failures or idmapd errors like the ones documented above are typically a result of either:
1. The username is known to the client but not known to the server, or
2. The idmapd domain name is set differently on the client than it is on the server.
Therefore, this issue can be fixed by insuring that the nfs server and client are configured with the same idmapd domain name (/etc/idmapd.conf) and both have knowledge of the usernames / accounts in question.
However, it is often not convenient to insure that both sides have the same user account knowledge, especially if the nfs server is a filer. The NFS community has recognized that this idmapd feature of NFSv4 is often more troublesome that it is worth, so there are steps and modifications coming into effect to allow the NFSv3 behavior to work even under NFSv4.
SUSE NFS clients on SLES 11 SP2 or higher have this ability, but it is not necessarily always the default behavior. Setting the kernel module parameter as described in the “Resolution” section of this document is needed. In mainstream Linux, the default behavior changes in kernel 3.3, i.e. to already have nfs4_disable_idmapping set to 1. So eventually (as newer kernels come into SUSE products) setting this manually will not be needed.
NOTE: Some NFSv4 servers may not be prepared to accept this behavior, either. Both sides need to understand this change. If using a Linux NFSv4 server, it may be necessary to use a distribution with kernel 3.4 or higher (for example, openSUSE 12.2 or higher, or upcoming SLES 12). For 3rd party filers, check the nfs configuration for settings related to idmap, uids, etc.
echo 1 > /sys/module/nfsd/parameters/nfs4_disable_idmapping