permission denied using mkdir on mounted remote filesystem

[Bob Purdy]

I have a system runing HPUX 11.) on a pair of L2000 servers in a clustered environment. We recently added two new filesystems to the system. These filesystem are mounted on the system directly and are remotely mounted as well on the same system. The problem we are having is that we can mkdir a new directory when accessing the one of the filesystems through the direct mount but not when trying to create it using the remote mount point. The permissions are all the same as well as the ownership. Any ideas would be appreciated.

[Steven E. Protter · Accepted solution]

Is the response the same on the node that is currently active and has the volume group mounted as the one that is not?

Lets say package shmuel is on node1 and vg02 is activated when the package starts.

can node1 do a mkdir while node2 can not?

This would be the behavior i sould expect becaue the volume group is not active on node 2.

If this is an NFS do an id command for the user on both systems. If the user on the system that can't mkdir doesn't include the same groups this can also trigger the problem.

SEP

[Martin Johnson]

I depends on the permissions given when the fiel systems is NFS mounted. USe SAM to look at Networking and Communications->Networked File systems->exported Local File Systems. Make sure it's read-write for all systems and read-write for root user acccess.

HTH
Marty

[Sanjay_6]

Hi,

What is the id that you are using to create the directory on this filesystem using the nfs mount point. If the filesystem was exported using rw permissin you should be able to create directories using unix uids which own the parent directories in the mount point.

You may not be able to do so using the root id if the nfs export does not allow root access to the nfs exported filesystem.

Take a look at the third solution over here,

http://docs.hp.com/cgi-bin/fsearch/framedisplay?top=/hpux/onlinedocs/B1031-90054/B1031-90054_top.html&con=/hpux/onlinedocs/B1031-90054/00/00/42-con.html&toc=/hpux/onlinedocs/B1031-90054/00/00/42-toc.html&searchterms=root&queryid=20040921-112012

Hope this helps.

regds

[Moderator edit: Removed the broken link. Please refer to https://support.hpe.com/]

[Bob Purdy]

The filesystem is remote mounted on both systems and the response is the same on both. Of course we cannot mkdir on the direct mount on the server where the vg is not activated but the response is the same when attempting the mkdir on the remote mount point. The filesystems are mounted using the automounter.

The users are the same on both servers. One of the filesystems seems to be working fine as do the original two filesystems.

I also verified the read/write parmissions.

[Mel Burslan]

let's say the scenario is

nodeA is NFS server and mounts the FS directly
nodeB is the NFS client mounts FS via NFS from nodeA

on nodeA, in the file /etc/exports, do you have the directive

/path/to/filesystem -access=blah1:blah2:...:blahN,root=nodeB

the 'root=nodeB' is the detemining factor if you can use the mkdir command on the NFS mounted filesystem. Otherwise -access:blahX directives give the remote nodes named blahX a read only access.

[Sundar_7]

The problem is obvious. Though you are accessing the remote mount point from the same system, it is as good as accessing the NFS filesystem of a different system since it has to go through all the NFS daemons for read/write access.

By default, root of NFS client will not be mapped to the root of NFS server. So even if you are root in the NFS client, you will only get the permissions of nobody (UID -2). For the very reason you are not able to mkdir on the remote mounted filesystem


Try this

# exportfs -iv -o root=: /NFS-export

Say

yourhostname: node1
MC-SG-Package-DNS-name: pkg1
NFS-export = /app1 the local filesystem that you are exporting to yourself

# exportfs -iv -o root=node1:pkg1 /app1

[Bob Purdy]

Adding the server host names and the service guard package names to the root access list solved the problem, but now I am confused why it only affected the on filesystem.

[Sanjay_6]

Hi,

Maybe the filesystem for which you did not have any problem was owned by root and the one for which you had problems was owned by another user id. Just a guess. You can also check the directory permissions of the mount points before and after the mount.

Hope this helps.

Regds

[Sundar_7]

Sanjay: "Maybe the filesystem for which you did not have any problem was owned by root and the one for which you had problems was owned by another user id. Just a guess"

This cannot be the case, if you did nt add root= option to the exportfs command, requests from NFS client root will be assigned the UID of -2. So even if the remote mounted filesystem is owned by root, the system will treat the requests with the previlege of -2.

Bob:-

Are you saying, you had problems creating directory on one remote-mounted filesystem and not the other.

Could be that directory had write permissions for "OTHER" group.

Check the permissions of the remotemounted filesystem, I am positive it has write permissions for OTHER group like

-XXXYYYrwx

The above permission means, even if the NFS client root requests are assigned UID of -2, he can read/write to the directory due to the rwx permissions for the "WORLD"