CentOS下NFS共享存储环境搭建

在CentOS 6.9环境下搭建NFS共享,使用Yum安装

yum install nfs-utils -y

修改服务端配置文件/etc/exports如下:

# 格式:
# 作为共享的本地目录  主机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

客户端也需要安装nfs-utils

yum install nfs-utils -y

客户端挂载直接使用mount命令即可,也可以加入/etc/fstab

不过还是建议放在/etc/rc.local,防止客户端服务器重启时
如果访问NFS服务器超时会导致客户端服务器启动慢或者无法启动

挂载命令

mount -t nfs4 -o rw,intr,hard,proto=tcp,noatime,nodev,noexec,nosuid 192.168.1.22:/ /data/web/wwwroot/upload/

客户端使用NFSv4协议挂载时,访问共享文件会特别慢,查看日志/var/log/message会报以下错误:

Aug 25 16:19:13 localhost nfsidmap[5617]: nss_getpwnam: name 'root@localhost' does not map into domain 'localdomain'
Aug 25 16:19:13 localhost nfsidmap[5619]: nss_name_to_gid: name 'root@localhost' does not map into domain 'localdomain'

如使用chown修改共享文件权限时会报以下错误:

idmapd errors about "localdomain", or chown failing on nfs4 mount, with "invalid argument"

Google后,找到问题解决办法:https://www.novell.com/support/kb/doc.php?id=7014266

原文摘录如下:

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.

原来是因为NFv4使用了idmapd来传递确保用户身份,必须确保服务器和客户度必须具有相同的idmapd域名(/etc/idmapd.conf),但通常服务端是不可控的
因此解决办法就是降级到NFSv3协议,或者是修改NFS服务器端参数nfs4_disable_idmapping改为True

在服务端执行关闭NFSv4的idmapping用户映射的命令,并将其添加到/etc/rc.local里以便下次开机自动关闭,问题解决

echo 1 > /sys/module/nfsd/parameters/nfs4_disable_idmapping
订阅
提醒
0 评论
在线反馈
查看全部评论