Description of problem:
When the mode of a device node (eg: sda) or a socket on an NFS filesystem are
changed (on the client), the change succeeds, but then is overwritten within 30
seconds by the mode of the server's copy of the node/sock. It seems either the
chmod should fail or it should be recognized at sync time (and therefore
preserved locally). I doubt anyone expects it to change the server's copy of the
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. do either 'mksock foo' or '/dev/MAKEDEV -d `pwd` sda' on an NFS filesystem
2. chmod the new node/sock to 0777
3. (quickly) verify the mode now 0777
4. wait 30 seconds (at most)
5. re-observe the mode
the mode will have been reverted to the mode it was created with (0755)
the mode of the local copy is either immutable in the first place or stays
changed once chmod has succeeded
Dave, could you verify whether the mode of the device is set properly at any
time on the server? Which OS and revision is running on the server?
Do you know whether the mount is mounted with noac, or sync?
Would you be able to gather a tcpdump of the file creation, chmod, and
Well it appears there is not much we can do about this
because of how socket are created.
When a socket is created, an inode is also allocated. In the inode
there is an 'inode_operations' field that is set, usually by the
file system, to point to the appropriate file system specific operations.
In the case of NFS, these operations causes Over-The-Wire operations
then things like chmod are done.
Now the problem is the inode_operations field in the inode (that
is attached to the socket) are not being set with the NFS
specific operations, so when the chmod is done the NFS
opts are never called which means the permission bits are
only set locally (i.e. the server is never told of the change).
When the local cache expires, NFS will refresh its cache
with the server bits which in this case are the old
permission bits. Thats why the permission bits revert
after a few seconds.