• Choose a category
• All
• Classic-Fiction

By Root 573 0

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.

Asynchronous NFS error messages

This final section provides an in-depth look at how an NFS client does write-behind, and what happens if one of the write operations fails on the remote server. It is intended as an introduction to the more complex issues of performance analysis and tuning, many of which revolve around similar subtleties in the implementation of NFS.

When an application calls read( ) or write( ) on a local or Unix filesystem (UFS) file, the kernel uses inode and indirect block pointers to translate the offset in the file into a physical block number on the disk. A low-level physical I/O operation, such as "write this buffer of 1024 bytes to physical blocks 5678 and 5679" is then passed to the disk device driver. The actual disk operation is scheduled, and when the disk interrupts, the driver interrupt routine notes the completion of the current operation and schedules the next. The block device driver queues the requests for the disk, possibly reordering them to minimize disk head movement.