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 , 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: 

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 permissions, refusing access to anyone but the superuser. The 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 fixed the problem.