NFS

[Nobody's Hero]

OK I am in a bind here and I need some help please. My boss is about to show me the curb.

I am running samba on the HPUX box, and in order for me to control the permissions correctly on the NT side I need the perms to look like this:

drwxrwx--- 8 root root 75 Aug 28 11:24 fsdev
drwxrwx--- 8 root root 75 Aug 27 11:07 fsprd
drwxrwx--- 8 root root 75 Aug 28 14:46 fstst

770 and root:root

Now all my samba permissions are fine. The users are blocked and allowed to go where they want too.

BUUUUTTT, I nfs these files to another unix system and now, oracle users cant get into the NFS mounts because of the 770 and root:root perms on the system taht is handing out the files. Any ideas here or did I confuse everybody.

[Nobody's Hero]

Here is what I get on the NFS side when the psfin user tries to go to the nfs filesystem. Notice the 'SU' in the error message. Is this telling me something?

ihshp14:psfin> cd /app/psfin/fsdev/fsintfc
su: /app/psfin/fsdev/fsintfc: Permission denied.

[Kevin Wright]

So it sounds like you need to decide whether or not you want the NT/samba stuff to work or your other NFS client.
what options/permissions are you exporting the filesystems as?

[Umapathy S]

Robert,
This is really a permission problem.


The user ID and group ID mappings must be the same between client and
server. However, the server maps UID 0 (the superuser) to UID -2
before performing access checks for a client. This process prevents
gaining superuser privileges on remote file systems.


So you have only permissions for root:root.
HTH,
Umapathy

[Steven E. Protter]

Robert, post the contents of /etc/exports

It is probable that nfs access is being blocked by the settings there.

Again, its very important to understand under the permissions you currently have, the user that needs to access those directories must be part of the root group.

That's opennning up some security issues, unless the users are all admins.

If you can't change the permissions on the files, you have a problem. oracle user should NOT be part of the root group. To enable access to those files, you will have to add access to the other section.

I would suggest this:

drwxrwxr-x 8 root root 75 Aug 28 11:24 fsdev
drwxrwxr-x 8 root root 75 Aug 27 11:07 fsprd
drwxrwxr-x 8 root root 75 Aug 28 14:46 fstst

This will be achieved by

chomd a+rx fsdev
chomd a+rx fsprd
chomd a+rx fstst

You have to give execute permissions to allow users to cd into a directory, last I checked. Denying write permissions keeps things secure.

Now files in the actual directory can be given proper permissions to allow oracle to access them.

SEP

[Nobody's Hero]

/etc/exports om our unix/linux system looks like:
root@mahimahi fsdev]# more /etc/exports
/ASU/fstst ihshp15(rw,sync,no_acl,no_root_squash)
/ASU/fsdev ihshp14(rw,sync,no_acl,no_root_squash)
/ASU/fsprd ihshp8(rw,sync,no_acl,no_root_squash)
/ASU/hrprd ihshp1(rw,sync,no_acl,no_root_squash) ihshp14(rw,sync,no_acl,no_root_squash)
/ASU/hrpt ihshp1(rw,sync,no_acl,no_root_squash)
/ASU/hrtst ihshp15(rw,sync,no_acl,no_root_squash)
/ASU/hrdev ihshp14(rw,sync,no_acl,no_root_squash)

[Kevin Wright]

You can't have somebody NOT in the root group access those directories, so like I mentioned, if you HAVE to have 770 perms on those files, then you cannot export it successfully to different users. It's either one or the other.

I would change the group to oracle's group, and see what that does to your Samba setup.

[Sundar_7]

Hi Robert,

Most likely the problem is with the UID not matching in the NFS server and NFS client.

Just for testing purpose, add the option "anon=0" to ur /etc/exports and exportfs and then try from the client.

dont forget to remove the anon once u r done ;)

Sundar.