Red HatThis forum is for the discussion of Red Hat Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
And the directory permissions on the NFS server shared directory looks like:
drwxrws--- 3 oracle users 25 Jan 20 05:00 output
So I am slightly confused as I know the SETUID bit on the directory allows the group to run programs as the user, and the exports line above defaults anonymous users to the uid and gid of oracle and users and gid 1000 (dba group).
Does this mean UID and GID must match on new server? Does the user on the new server have to be the one who mounts?
I am receiving "access denied" when trying to mount.
Thanks for the help in advance.
edit: I should also add that the user accessing this mount exists on both systems but likely doesn't have the same password. Is this necessary?
Last edited by toledotown; 01-25-2018 at 12:42 PM.
Are you the administrator for the NFS server? Is 'servername.ourdomain.com' representative of the NFS client that needs access to the share?
Yes I am the admin. and that is the server that needs access to the share. The funny thing is I thought this was a NAT issue as my net admin removed NAT rules to this server and the mount works. However, I still get access denied on boot from the fstab entry but can mount using mount -a....
The other issue is that when viewing the mount on the NFS client, it shows all of the permissions as they exist on the NFS server but I would like it to show all of the permissions as a specific user (which is how the old NFS client shows the permissions).
The other issue is that when viewing the mount on the NFS client, it shows all of the permissions as they exist on the NFS server but I would like it to show all of the permissions as a specific user (which is how the old NFS client shows the permissions).
I think rpc.idmapd might be the culprit. Here are logs from both the old (working) NFS client (bottom) and new NFS client (broked):
Code:
[root@jobsub-test ~]# cat /var/log/messages | grep rpc.idmap
[root@jobsub-test ~]# cat /var/log/messages | grep nss
Jan 30 10:52:04 jobsub-test avahi-daemon[629]: WARNING: No NSS support for mDNS detected, consider installing nss-mdns!
Jan 30 13:04:41 jobsub-test avahi-daemon[634]: WARNING: No NSS support for mDNS detected, consider installing nss-mdns!
Jan 30 13:06:20 jobsub-test dracut: *** Including module: nss-softokn ***
Jan 30 13:28:37 jobsub-test avahi-daemon[609]: WARNING: No NSS support for mDNS detected, consider installing nss-mdns!
Jan 30 13:28:44 jobsub-test dracut: *** Including module: nss-softokn ***
Jan 30 15:46:25 jobsub-test avahi-daemon[609]: WARNING: No NSS support for mDNS detected, consider installing nss-mdns!
Jan 30 15:48:04 jobsub-test dracut: *** Including module: nss-softokn ***
Jan 30 15:54:07 jobsub-test avahi-daemon[606]: WARNING: No NSS support for mDNS detected, consider installing nss-mdns!
Jan 30 16:30:06 jobsub-test avahi-daemon[598]: WARNING: No NSS support for mDNS detected, consider installing nss-mdns!
Jan 30 16:31:43 jobsub-test dracut: *** Including module: nss-softokn ***
Jan 30 16:40:28 jobsub-test avahi-daemon[596]: WARNING: No NSS support for mDNS detected, consider installing nss-mdns!
Jan 30 16:42:05 jobsub-test dracut: *** Including module: nss-softokn ***
[root@jobsub-test ~]#
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Feb 1 14:42:31 jobsub-old rpc.idmapd[3672]: nss_getpwnam: name '1000' does not map into domain 'ourdomain.com'
Feb 1 14:42:31 jobsub-old rpc.idmapd[3672]: nss_getpwnam: name '2068' does not map into domain 'ourdomain.com'
Feb 1 14:42:31 jobsub-old rpc.idmapd[3672]: nss_getpwnam: name '1083' does not map into domain 'ourdomain.com'
Feb 1 14:42:31 jobsub-old rpc.idmapd[3672]: nss_getpwnam: name '1002' does not map into domain 'ourdomain.com'
Feb 1 14:42:31 jobsub-old rpc.idmapd[3672]: nss_getpwnam: name '2046' does not map into domain 'ourdomain.com'
Feb 1 14:59:19 jobsub-old rpc.idmapd[3672]: nss_getpwnam: name '1000' does not map into domain 'ourdomain.com'
Feb 1 14:59:19 jobsub-old rpc.idmapd[3672]: nss_getpwnam: name '2068' does not map into domain 'ourdomain.com'
Feb 1 14:59:19 jobsub-old rpc.idmapd[3672]: nss_getpwnam: name '1083' does not map into domain 'ourdomain.com'
Feb 1 14:59:19 jobsub-old rpc.idmapd[3672]: nss_getpwnam: name '1002' does not map into domain 'ourdomain.com'
Feb 1 14:59:19 jobsub-old rpc.idmapd[3672]: nss_getpwnam: name '2046' does not map into domain 'ourdomain.com'
Feb 1 15:09:44 jobsub-old rpc.idmapd[3672]: nss_getpwnam: name '1000' does not map into domain 'ourdomain.com'
Feb 1 15:09:44 jobsub-old rpc.idmapd[3672]: nss_getpwnam: name '2068' does not map into domain 'ourdomain.com'
Feb 1 15:09:44 jobsub-old rpc.idmapd[3672]: nss_getpwnam: name '1083' does not map into domain 'ourdomain.com'
Feb 1 15:09:44 jobsub-old rpc.idmapd[3672]: nss_getpwnam: name '1002' does not map into domain 'ourdomain.com'
Feb 1 15:09:44 jobsub-old rpc.idmapd[3672]: nss_getpwnam: name '2046' does not map into domain 'ourdomain.com'
Feb 1 15:34:47 jobsub-old rpc.idmapd[3672]: nss_getpwnam: name '1000' does not map into domain 'ourdomain.com'
Feb 1 15:34:48 jobsub-old rpc.idmapd[3672]: nss_getpwnam: name '2068' does not map into domain 'ourdomain.com'
Feb 1 15:34:48 jobsub-old rpc.idmapd[3672]: nss_getpwnam: name '1083' does not map into domain 'ourdomain.com'
Feb 1 15:34:48 jobsub-old rpc.idmapd[3672]: nss_getpwnam: name '1002' does not map into domain 'ourdomain.com'
Feb 1 15:34:48 jobsub-old rpc.idmapd[3672]: nss_getpwnam: name '2046' does not map into domain 'ourdomain.com'
Feb 1 15:44:36 jobsub-old rpc.idmapd[3672]: nss_getpwnam: name '1000' does not map into domain 'ourdomain.com'
Feb 1 15:45:22 jobsub-old rpc.idmapd[3672]: nss_getpwnam: name '1000' does not map into domain 'ourdomain.com'
Feb 1 15:47:44 jobsub-old rpc.idmapd[3672]: nss_getpwnam: name '1000' does not map into domain 'ourdomain.com'
Feb 1 15:47:44 jobsub-old rpc.idmapd[3672]: nss_getpwnam: name '2068' does not map into domain 'ourdomain.com'
Feb 1 15:47:44 jobsub-old rpc.idmapd[3672]: nss_getpwnam: name '1083' does not map into domain 'ourdomain.com'
Feb 1 15:47:44 jobsub-old rpc.idmapd[3672]: nss_getpwnam: name '1002' does not map into domain 'ourdomain.com'
Feb 1 15:47:44 jobsub-old rpc.idmapd[3672]: nss_getpwnam: name '2046' does not map into domain 'ourdomain.com'
[root@jobsub-old BDEVLT]#
However, I still get access denied on boot from the fstab entry but can mount using mount -a....
I wonder if name resolution isn't working when your client system boots and fstab mounting is attempted.
Does running
Code:
mount -a
succeed with the remote share once the system is up? As an experiment, you could try substituting 'oradbs-bdev.ourdomain.com' with the actual IP address and see if that works. If that works at boot, then perhaps adding a manual hostname/IP mapping entry in /etc/hosts will be another option.
I wonder if name resolution isn't working when your client system boots and fstab mounting is attempted.
Does running
Code:
mount -a
succeed with the remote share once the system is up? As an experiment, you could try substituting 'oradbs-bdev.ourdomain.com' with the actual IP address and see if that works. If that works at boot, then perhaps adding a manual hostname/IP mapping entry in /etc/hosts will be another option.
Good idea.
Code:
mount -a
works post-boot.
I just changed to test but using IP did not resolve.
Do you actually need the remote file system to be mounted at boot? It might be better to consider using autofs to handle the mounting 'on demand' perhaps.
Do you actually need the remote file system to be mounted at boot? It might be better to consider using autofs to handle the mounting 'on demand' perhaps.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.