UID Processing - under the covers

  • If you are able to do everything but create a file in a NFS-mounted Byte File System directory,

  • but you see ACCESS DENIED or NOT OWNER when you attempt to create a file,

  • the UIDs defined for your AIX system are probably different from the UIDs defined for the VM user ID you've used on the mount.

Everything you do on the VM system uses the UID associated with the VM user ID you specified on the MOUNT. Let's call it VM SAM, and in this example, let's say that VM SAM's CP directory entry defines his UID as 123.

The AIX system is using the UID under which the create is issued. Let's call that AIX SAM. On the AIX system, SAM is defined to have a UID of 456.

AIX does all permission checking based on a UID of 123. The NFS client code in the AIX system sends the NFS server a create request which tells the server to set the owning UID of the new file to 123.

The NFS server is just trying to do what it is told. It must use two steps to satisfy the client's create request... it creates the file and then attempts to change the UID to 123 using chmod(). However, the POSIX/UNIX* rules say that in order to change the owner of a file you must be a super-user. VM SAM is not a super-user so the entire create request fails. (The create request MUST operate under the UID of 456, the UID associated with the verified user ID specified on the MOUNT, in order to meet VM security requirements.)

*UNIX is a registered trademark in the United States and other countries licensed exclusively through The Open Group.

Return to the main z/VM TCP/IP NFS Server Support page.