Unable to overwrite an existing File on NFS

[Girish Agarwal_1]

Hi All,
We have iomega NAS which is acting as anNFS server for one the directories.
The client is HPUX 10.20 and 11.11i machine. We ran a Oracle 8.0.5 hotbackup script which will put the data on this NFS share.
I have the following problem.
As any other user (e.g. oracle) except the local root user I can ceate,delete files on NFS share, but I cannot overwrite/append an existing file. Also, If after creating the file, I manually change the file permissions to 777 , then any user can do anything on the files. But there are some files in hotbackup which I cannot create in advance and change the permisions.
With the 11.11i client I don't have any problem for any user.
Since there is no problem, with 11.11i client, I am inclined to feel that there is absolutely no problem with NFS server(NAS).


Please advise,
Girish

[Steven E. Protter]

Ther probably isn't a problem with the NFS device, but don't totally rule it out. It could have access=hostname entries in its nfs configuration file that block access to one server or the other. Say read only access to the 10.20 box.

Do the users on both boxes have the same numeric ID.

If you run the id command for oracle on the 10.20 box is the numeric user id the same as on the 11.11 box?

If they are different, the NFS mount might have problems figuring out who really owns the files.

If the files were created by oracle user user 102 sya on 11.11 and oracle is user 108 on the 10.20 box, access could be denied on that basis.

This theory is proven partially by the fact that root user is good on both servers, what user id is always zero.

SEP

[James A. Donovan]

If you want the root user of your 10.20 client to have full access to the NFS share, then you need to modify the appropriate file (probably the exports file) on your NAS device. Sounds like your 11.11 client machine has already been given these permissions, so just follow what was done there.

[doug mielke]

...And on my Netapps NAS I need to run exportfs
after every change to the exports file.

Also, we have a constant problem with what SEP described. Seen as different owners / groups when NFS mounts are viewed from different clients, and it the user doesn't exist on that client, owner shows as something like 205.

[Bill Hassell]

There is no relationship between user and group ID's on *any* NFS server until you create that relationship. Using 777 is a very BAD way to fix any permissiom problem as you have just given every user the ability to trash the contents of the files. The NAS server is behaving correctly, just like any other NFS server. But the NAS server probably doesn't have a password file and has specific rules about how file and directory ownerships work for Unix clients.

Read carefully the mfr's documentation concerning users and groups and how they are handled. If the NAS server is just an intermediate storage location for both machines, then the problem is easy to solve. The passwd file in both machines must have the same UID and GID numbers for the users that will access the data. One way is to use NIS between the two machines. However, it is probably much simpler to match the only users that will be accessing the data (ie, oracle). On each machine, type the command:

id oracle

Changing the UID (and perhaps the GID) for a user will involve some work since the numeric value (not "oracle") is stored with each file's inode. So you have to reassign the UID:GID for every file on whichever server you pick to be changed. This would be the case for any NFS client/server.

[Girish Agarwal_1]

Hi,
I created a new NFS share on the NAS. and Mounted it on just one HPUX 10.20 client and again I have the same problem.

Thanks,
Girish

[Girish Agarwal_1]

Hi,
I Feel that setuid on the mounted Diretory/File is not working.Here is why I feel that
-rw-r--r-- nobody nogroup /test/test.txt
This is what the HPUX 10.20 client sees, when I log in as an oracle user. With setuid execution , my feeling would be that test.txt should be edited as as oracle user and since the user has rw permissions it should work. But it does not.
Also, If I change the permission to
-rw-rw-rw- nobody nogroup /test/test.txt I can edit the file the way I want.

In HPUX 11.11i I can edit the file as any user withour manually making any modification to the permissions.

Please suggest.

Thanks,
Girish

[Bill Hassell]

With the file permissions you see on 10.20 (owned by nobody:nogroup) it is absolutely correct that you cannot change the contents. The write bit is not set for others (and oracle user is 'other'). Setuid on a mountpoint means that the owner of an executable file will be the effective user when that process runs and doesn't affect the write permissions of a file. Setting the sticky bit (chmod 1777 some_directory) will prevent non-owners of a file from removing, moving or renaming the file but has no effect on the permission to change the contents of a file. If the 11i system allows the oracle user (I am assuming that oracle on your 11i machine has a UID greater than 100) to change the contents of a file owned by the nobody user, then this is incorect behavior. The nobody user is UID -2 in your password file and used whenever a filesystem is exported without the (security risk) -root= option.

[Elmar P. Kolkman]

You might have 2 problems...
1) the rights on the mountpoint (the directory on the 10.20 system under which you NFS-mount your filesystem) can cause problems. Unmount the filesystem and check them. It is a bug I ran into on 10.20 (and some other UX versions)... When mounted, the rights where correct (rwxr-xr-x oracle dba, for instance), but for some reason it inherited the invisible rights of the original directory (which was rwxr-xr-x root sys, resulting in oracle not being able to write to the directory!).

2) Over NFS, root is by default mapped to nobody. This can be changed on the exporting system, in your case the NAS. This is what SEP and the others pointed out.

If users and/or groups show up numeric or with different names on the two machines, your password and group files are not matching. That's why NFS is combined with NIS in a lot of environments.