HPUX NFS server to Linux Client issue

[Nick Lunt]

Hi folks,

I have an HPUX11.11 machine (colmore1) NFS exporting a filesystems to RedHat Enterprise 4 (vodka).

Here is the contents of /etc/exports on HPUX:
/wesapps/live/CDS/NEWCMS -anon=107,rw=vodka,access=vodka

Here is the fstab entry for vodka:
colmore1:/wesapps/live/CDS/NEWCMS /wesapps/live/CDS/NEWCMS nfs soft,intr 0 0

The filesytems mounts fine.

On colmore1(hpux) the oracle user is id 107 and on linux(vodka) the oracle user is id 501.

I need the linux oracle user to be able to write to the exported directory, but it cant.
Oracle user on linux can cd into the mounted NFS directory but an 'ls' returns 'Permission denied'.

Im stumped with this because in the past I have used the -anon=xxx directive in /etc/exports with no problems when the client was a solaris box.

Here is more diagnostics info -
An 'll' of the NEWCMS directory to be exported on colmore1(hpux):
drwxrwx--x 3 oracle dba 96 Feb 23 15:33 NEWCMS

An 'll' of the mounted NEWCMS directory on vodka(linux):
drwxrwx--x 3 107 102 96 Feb 23 15:33 NEWCMS

The user 107 does not exist on the linux box. Having mapped -anon to 107 in the exports file on the server (colmore1 hpux) I thought that it would map the unknown linux oracle id (501) to 107, the hpux oracle id ?

There is no user id 501 on the hpux box.

Any help would be really appreciated cos I'm stumped :( .

Cheers,
Nick .

[Nick Lunt]

Hmm just a quick update. After reading my own message I realised why oracle cannot 'ls' from linux client in the mounted directory - the permissions on the directory on the server(colmore1) are rwxrwx--x.

I've fixed this its now rwxrwxr-x, and now oracle can 'ls' from the linux box with no problems.

The real problem still remains however, oracle from the linux client cannot write to the NFS mounted directory.

[Muthukumar_5]

/wesapps/live/CDS/NEWCMS -anon=107,rw=vodka,access=vodka

change this to,

wesapps/live/CDS/NEWCMS -anon=501,rw=vodka,access=vodka

You have to configure NFS Client user ID not the server user ID.

Try to do again. If you define this then permission of 107 102 in the NFS client will be changed. You will get access. That is all ;)


--
Muthu

[Muthukumar_5]

Missed to say,

unmount the mounted file system and mount it again. It will work. You can see the permission of NEWCMS file as,

drwxrwx--x 3 107 dba 96 Feb 23 15:33 NEWCMS

However check this also,

# id dba

will give uid of dba and groud ID.

--
Muthu

[Senthil Kumar .A_1]

Hi Nick,

for the same reason, that ..still u haven't given write permission to others.

in you case it is rwxrwxr-x.

but making it rwxrwxrwx would make ur system very vulnerable.

By the way , why don't you syncronize the user id's of all users across ur unix systems. that would be hassle free as far as permissions are concerned.

You could use, NIS which is a off the shelf free product available on a HPUX box.

If you plan to have NIS, please revert back , we rather like to provide a solution.

Regards,
Senthil.

[Nick Lunt]

Hi,

I get the same error unfortunately.

Made the change you suggested, exportfs -a, mount -o remount on client, same error.

Stopped nfs on client. Stopped nfs.server on server. Restarted server then client. Same problem.

If the server maps anon to 501 how would that work ? There is no 501 id on the server ??

Ooh Im really confusing myself here .. ;)

[Arunvijai_4]

Hi Nick,

Unmount and mount FS again. It should work.
Check the user has necessary permissions.

-Arun

[Muthukumar_5]

Read exportfs man page for -access option as,

anon=uid
If a request comes from an unknown user, use uid as the
effective user ID.

Root users (user ID 0) are always treated as user
unknown by the NFS server unless they are included in
the root option below.

If the client is a UNIX system, only root users are
considered unknown. All other users are recognized
even if they are not in /etc/passwd.

The default value for uid is the user ID of user
nobody. If user nobody does not exist, the value -2 is
used. Setting the value of anon to -1 disables
anonymous access.

It is for NFS client side only. Try to change from 107 and 501. Hope one try will not be a problem ;)

PS: Don't panic on seeing problem. ITRC is here to help you ;)

--
Muthu

[Nick Lunt]

Hi Senthil,

your right we do not want to make the exported directory 777.

I have toyed with the idea of syncing the hpux oracle id's to the linux oracle id's. We have more linux than oracle so if I was to usermod the oracle user on the hpux machines Im worried about file permissions that already exist.

Ie, (hpux) 'usermod -u 501 oracle'
then 'find / -user 107 -exec chown oracle:dba {} \;'

Would that make it a clean user id change or could it introduce problems ?

Many thanks
Nick .

[Arunvijai_4]

Hi Nick,

Changing the UID may help. But make sure it wont trigger any other problem in Oracle.

_Arun

[Muthukumar_5]

Nick,

Why are you trying in file system permission and user modification with id's. Try simply as,

Change /etc/exports

-anon=507

and reexport it.

From client side remount and see whether it is working or it.

You've to take the decision of usermod -u 507 oracle after that.

??

--
Muthu

[Nick Lunt]

Hi Muthu,

(hpux) 'cat /etc/exports'
/wesapps/live/CDS/NEWCMS -anon=501

(linux) 'umount '
(hpux) 'exportfs -u /wesapps/live/CDS/NEWCMS'
(linux) 'mount -a -t nfs'

(linux) 'su - oracle'
(linux) 'touch /x'
'Permission denied'

hpux oracle uid = 107
linux oracle uid = 501

I have tried with both 107 and 501 for -anon option in /etc/exports.

[Nick Lunt]

Oops I did do the exports -a command on the server, just forgot to type it in ;)

[Nick Lunt]

I am getting the following message in /var/log/messages on the linux client -

mount.smbfs[3631]: tdb(/var/cache/samba/gencache.tdb): tdb_lock failed on list 55 ltype=1 (Bad file descriptor)

But we dont have smb running on this server.
Is this just a red herring or is smb involved in NFS for some reason .. ?

[Nick Lunt]

Please disregard my last message re smb, it's a red herring.

[Senthil Kumar .A_1]

Hi Nick,

Your commands to change the UID for oracle in hpux box sounds good. Except that you do the follwoing before you modify anything atall.

1) backup all your oracle related files that u are going to modify for a new UID before performing the change.so that you can restore it back,in case some things goes wrong. Better you do a preview of the files that are likely candidates for change by using "ll" with -exec option in find command and store it in a file also, before u do "chown".

2) make sure oracle is not running during this modification.

Regards,
Senthil Kumar .A

[Nick Lunt]

Just to let folk know what happened here.

I logged a call with HP, and was finally todl that the only way to get this to work is to make the dir to be exported on the nfs server 777 or change the uid and gid of the oracle users on either machine so that they are the same.

Neither of these options are suitable for me so were screwed with NFS from HPUX to Linux.

If anyone has got a Linux client to nfs mount HPUX and allowed a non-root user on the client to write to the directory I'd be interested to know how you did it.

Cheers,
Nick .

[Bill Thorsteinson · Accepted solution]

I have been exporting to Linux for a long
time. I do synchonize user ids.
Can you chagne your Linux oracle user id to
107?
Directoy access is standard 755.
/etc/exports lines are like
/u1 -access=@10.x.x.x/24:server.xxxx.com

We use either ip addresses or fully
quailified domain names in the access list.
We don't use both access and rw options.
Forward and reverse DNS loookups should
work.

I don't use uid remapping in NFS so I can't
help you there. However a quick look at
the documentation indicate that anon=107
is what you want.

To find what if anything needs to move
to setup 107 as oracle on linux
grep 107 /etc/passwd
find / -user 107 | tee files_107.txt
ps -fu 107
grep 501 /etc/passwd
find / -user 501 | tee files_501.txt
ps -fu 501

To change file ownership
find / -user xxx -print0 | xargs -o chown xxx

I had locking problems mounts from HPUX to
Linux. This traced to NFS activity
originating from insecure ports on HPUX.
This is resolved by adding the insecure and
insecure_locks to the export options
on Linux.

[Nick Lunt]

Hi Bill,

thanks for the info.

I have tried every combination of available options I can think of in the exports file.

There is no DNS issue, all the machines we have are on DNS. These machines also use data protector which will barf big style if DNS was an issue.

HP support have verified the problem in lab and cannot help me any further on the issue.

Thanks for the insecure/insecure_locks info.

I have looked at syncing the oracle uid's across machines but having never attempted it with such an important user before I'm very cautious of any problems this may cause. If we do go down that road then I may aswell setup NIS too as that's another thing we need to sort out here.

Thanks again,
Nick .

[Bill Thorsteinson]

I bypassed NIS and moved straight to LDAP,
as it appears to be a more secure solution.
I am still working some issues out before
a full rollout. There are NIS interfaces to
LDAP which is what I believe HPUX currently
uses.

For your NFS issue you may want to try
granting group write access to the files
and directories on HPUX.
Then add the HPUX group id on Linux if
it is not already there. Add your Linux
oracle user to the group and you
should have write access. This worked
for me before I got the ids syncronized.