我有两台运行RHEL6的服务器。 我有两个root权限。 主服务器，我将其称为server ，是一个数据库服务器。 应用服务器（我将称之为client通过NFS从server挂载一个目录。
在client和server上都有一个用户appuser 。 但是， client上的appuser的UID是502 。 appuser在server上的UID是506 。
两个用户都需要NFS共享上的读写function。 为了方便这个，我在server上创build了appuser所拥有的共享。
每个运行id appuser都会产生： uid=506(appuser) 。
当然， client不能识别所有权，因为appuser在client具有不同的ID。 所以我做了以下几点：
将client上的/ etc / passwd中的用户的UID更改为506。
将client上的appuser的$ HOME的所有权更改为appuser ，以便我可以login。
现在，当我从client端查看NFS共享时，我发现它拥有502 。 502是客户端上的appuser的旧的ID。 我无法从client更改NFS共享的所有权，因为这是一个实际驻留在server上的卷。
我需要确保NFS共享显示来自server和client的appuser所有权。
我更改客户端上的appuser id后错过了哪些步骤？
注 ：我没有重新启动client （或其他任何东西）。
id appuser可能会告诉你，shell仍然可以看到用户的旧UID。 注销并重新login。
好！ 我已经知道了。 尝试多次后在Bing上find它。 仍然不确定哪个东西是由问题固定的，有两种可能性。 但他们在这里。
互联网上有“告诉”，NFS v4可能有客户所有权的问题。 我不知道这是真的，我不在乎。 有人有他们称之为解决scheme。 所以我按照说明强制客户端挂载驱动器作为NFS版本3.所以我做的第一件事是改变我在/ etc / fstab从我的挂载线权限：
rw,hard,intr
对此：
rw,hard,intr,vers=3
另外，我在客户端启动了nfs守护进程，只是因为有人说要这样做：
service nfs start
然后，因为我遵循一些date指示，我检查了是否在客户端上运行portmap服务：
service portmap status
并迎接：
portmap: unrecognized service
然后我发现portmap现在被转换成rpcbind 。 所以：
service rpcbind status
我看到：
rpcbind dead but pid file exists
然后：
[root@myserver customers]# service rpcbind restart Stopping rpcbind: [FAILED] Starting rpcbind: [ OK ]
然后我检查了NFS共享的所有权，这是正确的！
文件所有权与用户ID保存。 当你正在查看这些文件并在502 – > 506更改之前将它们看作是appuser所拥有的文件时，它们实际上由用户ID 502（ ls -n will confirm）拥有。 这并没有改变。
因此，如果您想要将appuser视为所有者，则必须将文件的所有权从502更改为506.如果您没有对客户端的权限，则可能必须在服务器上执行此操作。
如何更改权限是一个不同的话题。 如果您无法访问服务器，则可以尝试使用新用户（假设您只有读取权限）复制这些文件，并稍后删除它们。 如果临时创build一个id为502的用户，可以更容易地更改502拥有的文件的权限（但不是所有权），重命名它们，或者在复制后删除它们。