Scientific Linux Forum.org



  Reply to this topicStart new topicStart Poll

> NFS problem
tankist02
 Posted: Aug 11 2011, 06:49 PM
Quote Post


SLF Newbie


Group: Members
Posts: 13
Member No.: 301
Joined: 16-June 11









Probably something simple, but I can't spot the problem. When trying to mount NFS share always get the following error:

CODE

# mount -t nfs -o intr clinton-s64:/data/andrew/dev/kmv/func_tests/data/aalm/cur_results /data/andrew/dev/kmv/func_tests/data/aalm/cur_results
mount.nfs: access denied by server while mounting clinton-s64:/data/andrew/dev/kmv/func_tests/data/aalm/cur_results


Server side:

CODE

SELinux is disabled
Firewall is disabled
hosts.allow and hosts.deny empty

# cat /etc/exports
/data/andrew/dev/kmv/func_tests/data/aalm/cur_results *(rw,sync,no_subtree_check)

#ll -d /data/andrew/dev/kmv/func_tests/data/aalm/cur_results
drwxr-xr-x 124 andrew andrew 12288 Aug 10 14:36 /data/andrew/dev/kmv/func_tests/data/aalm/cur_results

# exportfs
/data/andrew/dev/kmv/func_tests/data/aalm/cur_results
               <world>

# rpcinfo -p localhost
  program vers proto   port  service
   100000    4   tcp    111  portmapper
   100000    3   tcp    111  portmapper
   100000    2   tcp    111  portmapper
   100000    4   udp    111  portmapper
   100000    3   udp    111  portmapper
   100000    2   udp    111  portmapper
   100024    1   udp  42262  status
   100024    1   tcp  50554  status
   100003    2   tcp   2049  nfs
   100003    3   tcp   2049  nfs
   100003    4   tcp   2049  nfs
   100227    2   tcp   2049  nfs_acl
   100227    3   tcp   2049  nfs_acl
   100003    2   udp   2049  nfs
   100003    3   udp   2049  nfs
   100003    4   udp   2049  nfs
   100227    2   udp   2049  nfs_acl
   100227    3   udp   2049  nfs_acl
   100021    1   udp  49957  nlockmgr
   100021    3   udp  49957  nlockmgr
   100021    4   udp  49957  nlockmgr
   100021    1   tcp  37791  nlockmgr
   100021    3   tcp  37791  nlockmgr
   100021    4   tcp  37791  nlockmgr
   100005    1   udp  41470  mountd
   100005    1   tcp  38892  mountd
   100005    2   udp  56332  mountd
   100005    2   tcp  50524  mountd
   100005    3   udp  56570  mountd
   100005    3   tcp  43867  mountd



Client side:

CODE

# ll -d /data/andrew/dev/kmv/func_tests/data/aalm/cur_results
drwxr-xr-x. 2 andrew andrew 4096 Aug 10 21:54 /data/andrew/dev/kmv/func_tests/data/aalm/cur_results

# rpcinfo -p
  program vers proto   port  service
   100000    4   tcp    111  portmapper
   100000    3   tcp    111  portmapper
   100000    2   tcp    111  portmapper
   100000    4   udp    111  portmapper
   100000    3   udp    111  portmapper
   100000    2   udp    111  portmapper
   100024    1   udp  50897  status
   100024    1   tcp  45974  status


There is nothing in the server /var/log/message related to NFS after mounting attempts from the client.

What else should I check? Where else should I look for NFS/network messages?


PM
^
tankist02
 Posted: Aug 12 2011, 05:20 AM
Quote Post


SLF Newbie


Group: Members
Posts: 13
Member No.: 301
Joined: 16-June 11









Resolved by chmod -R 755 on the server exported directory. Some subdirectories that I tried to mount had wrong permissions. Duh.
PM
^
joutlan
 Posted: Aug 12 2011, 06:48 AM
Quote Post


SLF Founder
********

Group: Admins
Posts: 1109
Member No.: 1
Joined: 8-April 11









There's a thread around here where I had the same kind of "moment" regarding permissions. laugh.gif


--------------------
DΞLL Precision M6700: 17 inch NB//i7-quad w/USB 3.0, 16.0GB, Quadro K5000M 2.0GB DDR3, RGBLED //W8P64/Scientific Linux 6.4 x64
DΞLL Vostro 3350 Nirvana: 13 inch NB w/ IntelSSD// W8Px64 (Work;Games)
Nexus 4 //Android
PMEmail PosterUsers WebsiteIntegrity Messenger IM
^
zxq9
 Posted: Aug 12 2011, 08:12 AM
Quote Post


SLF Advocate
*****

Group: Members
Posts: 376
Member No.: 611
Joined: 5-August 11









Another (really weird) thing that can cause that error and yet not generate a single log message is having a --no-nfs-version=1 argument passed to rpc.mountd. This is wierd for two reasons:
  1. rpc.mountd isn't used in NFSv4 at all, and NFSv4 is usually the only thing you'll be connecting with by default (so why does rpc.mountd see fit to trip you up?)
  2. NFSv1 was never released, but remained in development long enough to give birth to NFSv2, which was used.

Check your /etc/sysconfig/nfs file for a line that says MOUNTD_NFS_V1="no" and remove it if its there. This was a big problem in some distros which had forever had lines to explicitely turn off NFS versions 1 through 3 -- and it worked its way by habit into more than a few nfs config files here and there. I just fixed this problem on my own network the other day, actually, because someone had put the line back into the nfs config file thinking it was missing.

Of course, that same error can come from permissions, as already discussed, or come from more mysterious naming mismatches or names not matching in nscd or rpc.idmapd caches... which is why new admins will pull their hair out for a whole day after checking and re-checking their settings (which are correct) to no avail, only to have everything magically work the next morning leaving nothing but mysteries in their wake. Particularly quirky is the way NFSv4 doesn't care the numerical value of the UID, but does care the numeric value of the GID when enforcing rwx permissions. (Why this was considered a good idea, we'll never know -- but only because I'm too lazy to dig through the nfs-kernel mailinglist and find where/when the discussion about this happened...)
PMEmail PosterUsers Website
^
0 User(s) are reading this topic (0 Guests and 0 Anonymous Users)
0 Members:

Topic Options Reply to this topicStart new topicStart Poll