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.
 |  |  |
| 15.4. Incorrect directory content caching |  | 15.6. Asynchronous NFS error messages |
