Incorrect mount point permissions (Managing NFS and NIS, 2nd Edition)

15.5. Incorrect mount point permissions

Not all problems involving NFS filesystems originate on the network or other fileservers. NFS filesystems closely resemble local filesystems, consequently common local system administration concepts and problem solving techniques apply to NFS mounted filesystems as well. A user reported problems resolving the "current directory" when inside an NFS mounted filesystem. The filesystem was automounted using the following direct map:

Excerpt from /etc/auto_direct:
/packages       -ro           aqua:/export

The user was able to cd into the directory and list the directory contents except for the ".." entry. He was not able to execute the pwd command when inside the NFS directory either:

$ cd /packages
$ ls -la
./..: Permission denied
total 6
drwxr-xr-x   4 root     sys          512 Oct  1 12:16 ./
drwxr-xr-x   2 root     other        512 Oct  1 12:16 pkg1/
drwxr-xr-x   2 root     other        512 Oct  1 12:16 pkg2/
$ pwd
pwd: cannot determine current directory!

He performed the same procedure as superuser and noticed that it worked correctly:

# cd /packages
# ls -la
total 8
drwxr-xr-x   4 root     sys          512 Oct  1 12:16 .
drwxr-xr-x  38 root     root        1024 Oct  1 12:14 ..
drwxr-xr-x   2 root     other        512 Oct  1 12:16 pkg1
drwxr-xr-x   2 root     other        512 Oct  1 12:16 pkg2
# pwd
/packages
# ls -ld /packages
drwxr-xr-x   4 root     sys          512 Oct  1 12:16 /packages

Note that the directory permission bits for /packages are 0755, giving read and execute permission to everyone, in addition to write permission to root, its owner. Since the filesystem permissions were not the problem, he proceeded to analyze the network traffic, suspecting that the NFS server could be returning the "Permission denied" error. snoop reported two network packets when a regular user executed the pwd command:

1   0.00000      caramba -> aqua         NFS C GETATTR3 FH=0222
  2   0.00050         aqua -> caramba      NFS R GETATTR3 OK

Packet 1 contains caramba 's request for attributes for the current directory having filehandle FH=0222. Packet 2 contains the reply from the NFS server aqua:

Excerpt of packet 2:
IP:   Source address = 131.40.52.125, aqua
IP:   Destination address = 131.40.52.223, caramba
IP:   No options
IP:   

...

NFS:  ----- Sun NFS -----
NFS:  
NFS:  Proc = 1 (Get file attributes)
NFS:  Status = 0 (OK)
NFS:    File type = 2 (Directory)
NFS:    Mode = 0755
NFS:     Setuid = 0, Setgid = 0, Sticky = 0
NFS:     Owner's permissions = rwx
NFS:     Group's permissions = r-x
NFS:     Other's permissions = r-x
NFS:    Link count = 4, User ID = 0, Group ID = 3
NFS:    File size = 512, Used = 1024
NFS:    Special: Major = 0, Minor = 0
NFS:    File system id = 584115552256, File id = 74979
NFS:    Last access time      = 03-Oct-00 00:41:55.160003000 GMT
NFS:    Modification time     = 01-Oct-00 19:16:32.399997000 GMT
NFS:    Attribute change time = 01-Oct-00 19:16:32.399997000 GMT
NFS:  
NFS:

Along with other file attributes, the NFS portion of the packet contains the mode bits for owner, group and other. These mode bits were the same as those reported by the ls -la command, so the problem was not caused by the NFS server either.

Because this was an automounted filesystem, we suggested rebooting caramba in single-user mode to look at the mount point itself, before the automounter had a chance to cover it with an autofs filesystem. At this point, we were able to uncover the source of the problem:

Single-user boot:
# ls -ld /packages
drwx------   2 root     staff        512 Oct  1 12:14 /packages

The mount point had been created with 0700 permissions, refusing access to anyone but the superuser. The 0755 directory permission bits previously reported in multi-user mode were those of the NFS filesystem mounted on the /packages mount point. The NFS filesystem mount was literally covering up the problem.

In Solaris, a lookup of ".." in the root of a filesystem results in a lookup of ".." in the mount point sitting under the filesystem. This explains why users other than the superuser were unable to access the ".." directory -- they did not have permission to open the directory to read and traverse it. The pwd command failed as well when it tried to open the ".." directory in order to read the contents of the parent directory on its way to the top of the root filesystem. The misconstrued permissions of the mount point were the cause of the problem, not the permissions of the NFS filesystem covering the mount point. Changing the permissions of the mount point to 0755 fixed the problem.