Odd NFS Share Issue...?

Turns out that it was a bug...
rhn.redhat.com | Red Hat Support
https://bugzilla.redhat.com/show_bug.cgi?id=143897

So ServerA has two NFS shares on it...

/Here

/Some/Other/Share

ServerB can mount /Here but not /Some/Other/Share

There is no error message - the mount command just causes my ssh session to hang.

(mount -t nfs ServerA:/Some/Other/Share /Some/Folder)

Permissions look good & it's shared rw / mounted rw

No Selinux

Not a firewall issue because the other share works

I have used IP rather than hostname

I'm really at a loss... so, if anyone has any ideas / things they would suggest I check - it would be greatly appreciated!

Edit:

Just want to add: I get " authenticated mount request from" on the nfs server, so form there it's looking good...

Find more posts tagged with

Comments

UnixGuy

Ok let's try one by one.

1. On serve A, go # cd /Some/Other/Share

try to create a text file and read write on it...just to make sure the directory is ok.

2. On server A, ls -ltr /Some/Other/Share

check the permissions and the owner and the group...make sure it's identical to /Here.

3. df -k on Server B...cross check and confirm that you are mounting on a free directory that is not your "current directoy" and it's not occupied.

jbrad95706

UnixGuy wrote: »

Ok let's try one by one.

1. On serve A, go # cd /Some/Other/Share

try to create a text file and read write on it...just to make sure the directory is ok.

2. On server A, ls -ltr /Some/Other/Share

check the permissions and the owner and the group...make sure it's identical to /Here.

3. df -k on Server B...cross check and confirm that you are mounting on a free directory that is not your "current directoy" and it's not occupied.

1. I can create, edit, and remove files in that directory.
3. No issue here.

2. The permissions are not the same; however, I have requested that for troubleshooting we change them to be.

There's a series of different owners, permissions, acls in the path.

(Think of the game "Pick-up-sticks" but with permissions, etc...)

Edit: The root of the path has the same permissions, and I tired mounting just that folder, but I ran into the same issue.

Edit: Also, showmount -a shows both the root of the path and the path mounted. But I am only exporting the full path... is it possible that it is being shared in another way, and this is causing an issue with nfs... I have read that you can not share both the root and the path with nfs.

Edit: This folder one ServerA is "really" sitting on an emc storage device. I don't think that this would cause an issue - as far as the system is concerned it's a scsi drive. (I think)

UnixGuy

ok, I got lost a bit.

showmount -a on Server A shows that the directories are mounted correctly on Server A ? you was able to generate I/O on these directories, no issues there.

showmount -a on Server B ? anything odd ? you don't see this "ServerA:/Some/Other/Share /Some/Folder" mounted on Server B right ?

Now for the storage difference...As of my knowledge, this should be irrelevant to network sharing. I don't think the problem is there, as long as the directory is accessible from Server A itself...the media should be transparent to Server B in theory.

I hope this command works on Red Hat, try it out:

On Server A:

# fstype /Here

# fstype /Some/Other/Share

On Server B:

# fstype /Some/folder

if this command doesn't work on Red Hat, just lookup the command that gives you the characteristic of the file system. While this would be a rare incident, just compare the "fragment size, sector size, inodes" of both file systems on Server A & B.

Let us know if there's any difference.

jbrad95706

UnixGuy wrote: »

ok, I got lost a bit.

showmount -a on Server A shows that the directories are mounted correctly on Server A ? you was able to generate I/O on these directories, no issues there.

showmount -a on Server B ? anything odd ? you don't see this "ServerA:/Some/Other/Share /Some/Folder" mounted on Server B right ?

Now for the storage difference...As of my knowledge, this should be irrelevant to network sharing. I don't think the problem is there, as long as the directory is accessible from Server A itself...the media should be transparent to Server B in theory.

I hope this command works on Red Hat, try it out:

On Server A:

# fstype /Here

# fstype /Some/Other/Share

On Server B:

# fstype /Some/folder

if this command doesn't work on Red Hat, just lookup the command that gives you the characteristic of the file system. While this would be a rare incident, just compare the "fragment size, sector size, inodes" of both file systems on Server A & B.

Let us know if there's any difference.

1. On both systems showmount is now showing the correct info. (There was some old info in the rmtab file...)

2. I can still not mount the share.

3. On the server that is sharing - I can write to the folders.

4. fstype doesn't work. I'll have to do a little poking around to find the rhel tool for gathering this info - I'll get back to you with the sector/etc... results. (df -T does list the filesystem type as ext3)

UnixGuy

jbrad95706 wrote: »

1. On both systems showmount is now showing the correct info. (There was some old info in the rmtab file...)

2. I can still not mount the share.

3. On the server that is sharing - I can write to the folders.

4. fstype doesn't work. I'll have to do a little poking around to find the rhel tool for gathering this info - I'll get back to you with the sector/etc... results. (df -T does list the filesystem type as ext3)

since showmount gave initial inaccurate results, looks like something was hanging.

I on Server B...try to remove the target directory, and then mkdir again....Also, try to unshare and then unmount the directory in question on Server A. Then mount it and share it and try to mount it in Server B.

Sometimes NFS hangs like this for different reasons such as delays in networks or somebody might have tried to unmount it or unshare while some users are accessing...things like that.

jbrad95706

UnixGuy wrote: »

since showmount gave initial inaccurate results, looks like something was hanging.

I on Server B...try to remove the target directory, and then mkdir again....Also, try to unshare and then unmount the directory in question on Server A. Then mount it and share it and try to mount it in Server B.

Sometimes NFS hangs like this for different reasons such as delays in networks or somebody might have tried to unmount it or unshare while some users are accessing...things like that.

I removed and re-added the mount point, and tried to remount, but the system still hangs.

I've unshared the directory, and now I am only trying to share the root of the path. Still no luck.

Just to add a little more info...

If I'm watching /var/log/messages on ServerA (tail -f /var/log/messages)

When I try and mount the share, I get the message:

Dec 3 13:00:00 ServerA mountd[25209]: authenticated mount request from ServerB-IP:PORT for /Some (/Some)

...but my ssh session to ServerB just hangs at this point, and the share never mounts.

[root@ServerB ~]#mount -t nfs ServerA:/Some /Mount/Point

(Hung)

Edit: I have also tried to mount this share on other servers, with no joy.

Edit: One more thing.... both of the shares are "really" sitting on an emc storage device, but there is a difference... one is mounted to ServerA with acl support and one isn't. The one without is the one that works. I just put in the request to set them both with or without to see if this breaks/fixes one of the shares.

UnixGuy

Since you checked everything...

I have no experience with EMC itself...but tell me, by ACL support you mean ACL on your file system in Server A or something in EMC storage side ? can you try to edit that and see ?

jbrad95706 wrote: »

I removed and re-added the mount point, and tried to remount, but the system still hangs.

I've unshared the directory, and now I am only trying to share the root of the path. Still no luck.

Just to add a little more info...

If I'm watching /var/log/messages on ServerA (tail -f /var/log/messages)

When I try and mount the share, I get the message:

Dec 3 13:00:00 ServerA mountd[25209]: authenticated mount request from ServerB-IP:PORT for /Some (/Some)

...but my ssh session to ServerB just hangs at this point, and the share never mounts.

[root@ServerB ~]#mount -t nfs ServerA:/Some /Mount/Point (Hung)

Edit: I have also tried to mount this share on other servers, with no joy.

Edit: One more thing.... both of the shares are "really" sitting on an emc storage device, but there is a difference... one is mounted to ServerA with acl support and one isn't. The one without is the one that works. I just put in the request to set them both with or without to see if this breaks/fixes one of the shares.

jbrad95706

UnixGuy wrote: »

Since you checked everything...

I have no experience with EMC itself...but tell me, by ACL support you mean ACL on your file system in Server A or something in EMC storage side ? can you try to edit that and see ?

It's the linux filesystem acl. (getfacl/setfacl --- from fstab -> defaults,acl)

UnixGuy

jbrad95706 wrote: »

It's the linux filesystem acl. (getfacl/setfacl --- from fstab -> defaults,acl)

Ok then, so only specific set of users on Server A are allowed to use that directory...I think u should remove ACL

jbrad95706

UnixGuy wrote: »

Ok then, so only specific set of users on Server A are allowed to use that directory...I think u should remove ACL

I put in a request to do that for troubleshooting, but it was shot down...

I'm trying to recreate the issue on another server - one that I will be able to make the change one.

UnixGuy

jbrad95706 wrote: »

I put in a request to do that for troubleshooting, but it was shot down...

I'm trying to recreate the issue on another server - one that I will be able to make the change one.

I think this is the reason, because depend on the ACL...most probably it allows only certain users on Server A to access it...so it should prevent Server B from having Read/Write access for sure. it makes sense now

you try it and let us know the result

jbrad95706

UnixGuy wrote: »

I hope this command works on Red Hat, try it out:

On Server A:

# fstype /Here

# fstype /Some/Other/Share

On Server B:

# fstype /Some/folder

if this command doesn't work on Red Hat, just lookup the command that gives you the characteristic of the file system. While this would be a rare incident, just compare the "fragment size, sector size, inodes" of both file systems on Server A & B.

Let us know if there's any difference.

On RH tune2fs gives me the info I needed for that, and everything looked good.

As far as checking out the ACL issue - this issue has been put on hold at the moment, but when I get back to it / find the issue - I'll update this thread.

Thanks again!

jbrad95706

Turns out that it was a bug...
rhn.redhat.com | Red Hat Support
https://bugzilla.redhat.com/show_bug.cgi?id=143897

Thanks for you help!