So, I have SuSE 9.0 server with three drives. sda1 - mounts on / sdb1 - mounts on /data sdc1 - mounts on /data/moredata I have /data exported under NFS and I have it setup as a Samba share. My MS boxes can see everything as expected (both /data and /data/moredata). They can also see everything if they connect with an NFS client for Windows (comes with MS Services For Unix). My SuSE 9.1 box and a different 9.0 box can both mount a smb share and see the contents of the entire tree (/data and /data/moredata). The problem I can't figure out is if I mount /data through nfs on either SuSE workstation, I can only see the contents of /data. If I cd into /data/moredata the directory is empty, even though I know data is in the there. What is even stranger is if I create anything in /data/moredata from either SuSE workstation, both workstations can see the newly created files/folders, but all of the other machines can't. That is until I unmount sdc1 from /data/moredata. Then if I look into the folder that serves as the mount point, I find the files/folders that the SuSE workstations created. It is as if the SuSE NFS clients don't recognize the folder /data/moredata as a mount point and thus do not try to write anything to the proper volume. So my question is, has anyone else see this problem, and if so, what was the solution? Thanks in advance. Ken
We had a very similar problem with SuSE9.1 NFS clients and empty remote mounts. Try these mount options in your /etc/fstab nfsserver:/export /mnt/mount nfs nfsvers=2,rsize=8192,wsize=8192,timeo=30,intr,retrans=30,soft specify nfsvers=2 or nfsvers=3 and try both. If this won't work then probably you'll have load plain 2.6.8.1 kernel which has a fix for NFS problem. Compile it, install newer util-linux and the problem should go away. That is how we fixed it in our eng. dept. Alex On Wed, 1 Sep 2004, Ken Gramm wrote:
So, I have SuSE 9.0 server with three drives.
sda1 - mounts on / sdb1 - mounts on /data sdc1 - mounts on /data/moredata
I have /data exported under NFS and I have it setup as a Samba share.
My MS boxes can see everything as expected (both /data and /data/moredata). They can also see everything if they connect with an NFS client for Windows (comes with MS Services For Unix).
My SuSE 9.1 box and a different 9.0 box can both mount a smb share and see the contents of the entire tree (/data and /data/moredata).
The problem I can't figure out is if I mount /data through nfs on either SuSE workstation, I can only see the contents of /data. If I cd into /data/moredata the directory is empty, even though I know data is in the there. What is even stranger is if I create anything in /data/moredata from either SuSE workstation, both workstations can see the newly created files/folders, but all of the other machines can't. That is until I unmount sdc1 from /data/moredata. Then if I look into the folder that serves as the mount point, I find the files/folders that the SuSE workstations created. It is as if the SuSE NFS clients don't recognize the folder /data/moredata as a mount point and thus do not try to write anything to the proper volume.
So my question is, has anyone else see this problem, and if so, what was the solution?
Thanks in advance.
Ken
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
On Wed, 2004-09-01 at 15:28, Alex Daniloff wrote:
We had a very similar problem with SuSE9.1 NFS clients and empty remote mounts.
Try these mount options in your /etc/fstab
nfsserver:/export /mnt/mount nfs nfsvers=2,rsize=8192,wsize=8192,timeo=30,intr,retrans=30,soft
specify nfsvers=2 or nfsvers=3 and try both.
If this won't work then probably you'll have load plain 2.6.8.1 kernel which has a fix for NFS problem. Compile it, install newer util-linux and the problem should go away. That is how we fixed it in our eng. dept.
Alex
Thanks for the reply: I tried this option also. Again, it didn't work. Looks like a kernel recompile is in my future. :-) K
On Wed, Sep 01, 2004 at 11:32:05AM -0500, Ken Gramm wrote:
So, I have SuSE 9.0 server with three drives.
sda1 - mounts on / sdb1 - mounts on /data sdc1 - mounts on /data/moredata
I have /data exported under NFS and I have it setup as a Samba share.
My MS boxes can see everything as expected (both /data and /data/moredata). They can also see everything if they connect with an NFS client for Windows (comes with MS Services For Unix).
My SuSE 9.1 box and a different 9.0 box can both mount a smb share and see the contents of the entire tree (/data and /data/moredata).
The problem I can't figure out is if I mount /data through nfs on either SuSE workstation, I can only see the contents of /data. If I cd into /data/moredata the directory is empty, even though I know data is in the there. What is even stranger is if I create anything in /data/moredata from either SuSE workstation, both workstations can see the newly created files/folders, but all of the other machines can't. That is until I unmount sdc1 from /data/moredata. Then if I look into the folder that serves as the mount point, I find the files/folders that the SuSE workstations created. It is as if the SuSE NFS clients don't recognize the folder /data/moredata as a mount point and thus do not try to write anything to the proper volume.
So my question is, has anyone else see this problem, and if so, what was the solution?
From man page of exports:
nohide This option is based on the option of the same name provided in IRIX NFS. Normally, if a server exports two filesystems one of which is mounted on the other, then the client will have to mount both filesystems explicitly to get access to them. If it just mounts the parent, it will see an empty directory at the place where the other filesystem is mounted. That filesystem is "hid den". Setting the nohide option on a filesystem causes it not to be hid den, and an appropriately authorised client will be able to move from the parent to that filesystem without noticing the change. However, some NFS clients do not cope well with this situation as, for instance, it is then possible for two files in the one apparent filesystem to have the same inode number. The nohide option is currently only effective on single host exports. It does not work reliably with netgroup, subnet, or wild card exports. This option can be very useful in some situations, but it should be used with due care, and only after confirming that the client sys tem copes with the situation effectively. The option can be explicitly disabled with hide. Regards, -Kastus
On Wed, 2004-09-01 at 19:16, Kastus wrote:
From man page of exports:
nohide This option is based on the option of the same name provided in IRIX NFS. Normally, if a server exports two filesystems one of which is mounted on the other, then the client will have to mount both filesystems explicitly to get access to them. If it just mounts the parent, it will see an empty directory at the place where the other filesystem is mounted. That filesystem is "hid den".
Setting the nohide option on a filesystem causes it not to be hid den, and an appropriately authorised client will be able to move from the parent to that filesystem without noticing the change.
However, some NFS clients do not cope well with this situation as, for instance, it is then possible for two files in the one apparent filesystem to have the same inode number.
The nohide option is currently only effective on single host exports. It does not work reliably with netgroup, subnet, or wild card exports.
This option can be very useful in some situations, but it should be used with due care, and only after confirming that the client sys tem copes with the situation effectively.
The option can be explicitly disabled with hide.
Regards, -Kastus
Thanks for the reply, I have already tried the nohide option. It didn't work. I'm probably wrong, but to me, the passage: Normally, if a server exports two filesystems one of which is mounted on the other, then the client will have to mount both filesystems explicitly to get access to them. If it just mounts the parent, it will see an empty directory at the place where the other filesystem is mounted. That filesystem is "hid den". refers to if you have folder /x exports as /x and folder /x/y exported as /x/y then the nohide option would work. But that isn't the case here. I only have folder /x exported and the SuSE clients can't follow the tree to /x/y/z where z is a different partition mounted on folder z. Samba shares can follow it and so can MS NFS clients for Windows. On a side note, I have since discovered a discussion from back in '96 talking about how NFSv4 will be able to cross mount points but that version 2 and 3 are not capable of doing it. http://playground.sun.com/pub/nfsv4/nfsv4-wg-archive/1996/0004.html So I guess I will have to recompile my kernel and enable NFSv4 and see if that fixes my problem. K
On Wednesday 01 Sep 2004 17:32 pm, Ken Gramm wrote:
So, I have SuSE 9.0 server with three drives.
sda1 - mounts on / sdb1 - mounts on /data sdc1 - mounts on /data/moredata
I have /data exported under NFS and I have it setup as a Samba share.
My MS boxes can see everything as expected (both /data and /data/moredata). They can also see everything if they connect with an NFS client for Windows (comes with MS Services For Unix).
My SuSE 9.1 box and a different 9.0 box can both mount a smb share and see the contents of the entire tree (/data and /data/moredata).
The problem I can't figure out is if I mount /data through nfs on either SuSE workstation, I can only see the contents of /data.
The nohide option is no use for you here since it will only work on single-host exports - i.e. entries like: /data 192.168.0.1(....) In your case, with multiple hosts, you have no choice but to explicitly export and mount each file system. I would SERIOUSLY recommend re-organising so that nfs mounts do not occur within nfs mounts as this can lead to several problems... Dylan -- "I see your Schwartz is as big as mine" -Dark Helmet
participants (4)
-
Alex Daniloff -
Dylan -
Kastus -
Ken Gramm