Bug 68064 - nohide option is no longer working right
nohide option is no longer working right
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: nfs-utils (Show other bugs)
7.3
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Pete Zaitcev
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-07-05 20:44 EDT by Joao Veiga
Modified: 2007-04-18 12:43 EDT (History)
1 user (show)

See Also:
Fixed In Version: 9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-10-08 15:51:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Joao Veiga 2002-07-05 20:44:53 EDT
From Bugzilla Helper: 
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.0.0-10; Linux 2.4.18-5; X11; 
i686; en, en_US) 
 
Description of problem: 
After I installed the latest updates (including kernel-2.4.18-5 and 
glibc-2.2.5-36) on top of the 7.3 installation, the nohide option makes no 
effect anymore. The same /etc/exports used before no longer allows filesystems 
mounted on an exported filesystem to be seen on the nfs client. 
 
Version-Release number of selected component (if applicable): 
nfs-utils-0.3.3-5 
 
How reproducible: 
Always 
 
Steps to Reproduce: 
1. Mount a couple of filesystems on a directory belonging to a other 
filesystem 
2. Use the nohide option on /etc/exports, to export the "top" and other 
filesystems 
3. Mount the first exported fs on a nfs client 
  
 
Actual Results:  The other filesystems do not show on the client. 
 
Expected Results:  The filesystems mounted on the first exported filesystem 
should appear on the client (it used to work before the latest updates). 
 
Additional info: 
 
Client and server were using the standard RH 7.3 installation versions (kernel 
2.4.18-3). After both were upgraded with the latest updates (including kernel 
2.4.18-5 and glibc 2.2.5-36), nohide stopped working (not tested extensively 
with RH 7.3 and 2.4.18-3, but tested extensively with RH 7.2 and 2.4.18) 
On the server (phoenix): 
ph /root # exportfs -v 
/home/jsveiga/news 
                alpha.home(rw,async,wdelay,nohide,no_root_squash) 
/home/40g       alpha.home(rw,async,wdelay,nohide,no_root_squash) 
/home/40g       gw.home(ro,async,wdelay,nohide,no_root_squash) 
/home/20g       alpha.home(rw,async,wdelay,nohide,no_root_squash) 
/home           alpha.home(rw,async,wdelay,nohide,no_root_squash) 
/big            alpha.home(rw,async,wdelay,nohide,no_root_squash) 
/big            gw.home(ro,async,wdelay,nohide,no_root_squash) 
ph /root # mount | grep home 
/dev/hda7 on /home type ext3 (rw) 
/dev/hda8 on /home/jsveiga/news type ext3 (rw) 
/dev/hdd1 on /home/20g type ext3 (ro,noexec,nosuid,nodev) 
/dev/hdc1 on /home/40g type ext3 (ro,noexec,nosuid,nodev) 
ph /root # ls /home/jsveiga/news | wc -l 
     63 
ph /root # ls /home/40g | wc -l 
      5 
ph /root # 
 
On the client: 
al /etc # grep phoenix fstab 
phoenix:/big            /phoenixbig             nfs     noauto,user,exec        
0 0 
phoenix:/home/          /phoenixhome            nfs     noauto,user,exec        
0 0 
al /etc # mount | grep phoenix 
phoenix:/home/ on /phoenixhome type nfs 
(rw,nosuid,nodev,addr=192.168.168.5,user=jsveiga) 
al /root # ls /phoenixhome/40g/ | wc -l 
      0 
al /root # ls /phoenixhome/jsveiga/news/ | wc -l 
      0 
al /root # 
 
Strangely enough, sometimes one (and only one) of the "indirectly exported" fs 
shows up normally on the client (requires umounting,  restarting nfs on the 
server, and mounting again - it a lottery).
Comment 1 Joao Veiga 2002-07-05 22:21:42 EDT
REALLY ODD: MAY POINT TO THE CAUSE: 
I've tested several sequences-of-doing things, and found this: 
Without touching the server: 
- if I umount and mount the "parent" from the client (/phoenixhome/) and then 
cd to one of the "child" fs and "ls" from there, the child fs's disappear: 
al /home/jsveiga $ umount /phoenixhome/; mount /phoenixhome/ 
al /home/jsveiga $ cd /phoenixhome/40g/ 
al /phoenixhome/40g $ ls 
al /phoenixhome/40g $ cd 
al /home/jsveiga $ ls /phoenixhome/20g/ /phoenixhome/40g/ 
/phoenixhome/20g/: 
 
/phoenixhome/40g/: 
al /home/jsveiga $ 
 
- if I umount and mount the "parent" from the client (/phoenixhome/) and first 
"ls" them without "cding" there, then "child" fs's are there (and won't 
disappear): 
al /home/jsveiga $ umount /phoenixhome/; mount /phoenixhome/ 
al /home/jsveiga $ ls /phoenixhome/20g/ /phoenixhome/40g/ 
/phoenixhome/20g/: 
lost+found  video 
 
/phoenixhome/40g/: 
jb  lost+found  raid  winfiles 
al /home/jsveiga $ cd /phoenixhome/40g/ 
al /phoenixhome/40g $ ls 
jb  lost+found  raid  winfiles 
al /phoenixhome/40g $ 
 
- I can even selectively "save" one "child" by "ls"ing it and then "cd"ing to 
the other (this is why I though "sometimes" one of the fs shows up): 
al /home/jsveiga $ umount /phoenixhome/; mount /phoenixhome/ 
al /home/jsveiga $ ls /phoenixhome/40g/ 
jb  lost+found  raid  winfiles 
al /home/jsveiga $ cd /phoenixhome/20g/ 
al /phoenixhome/20g $ ls 
al /phoenixhome/20g $ cd 
al /home/jsveiga $ ls /phoenixhome/20g/ /phoenixhome/40g/ 
/phoenixhome/20g/: 
 
/phoenixhome/40g/: 
jb  lost+found  raid  winfiles 
al /home/jsveiga $ 
 
I suppose this makes it easier to find the cause of the problem. Looks like 
the first access to the indirectly exported (nohide) fs being an "ls" from 
"outside" it or from "inside" it differently initializes the access to it.
Comment 2 Pete Zaitcev 2003-10-06 19:28:14 EDT
Poking steved.
Comment 3 Steve Dickson 2003-10-07 17:19:07 EDT
Using the kernel-2.4.18-5smp kernel along with the nfs-utils-0.3.3-4 rpm
I am unable to reproduce this problem (i.e.everything works as expected).

Questions:

1) Are alpha.home and gw.home DNS-able (or in /etc/host) ip addresses 
   (i.e. they are not netgroups or something of that nature)?
2) The client is either alpha.home or gw.home?
3) Does /proc/fs/nfs/exports show all three exports (i.e /home, /home/40g
   and /home/20g)?
4) Does exportfs -rv talk about exporting things to the kernel
   (i.e. "exporting alpha.home:/home/40g to kernel")



Comment 4 Joao Veiga 2003-10-08 08:04:20 EDT
1) Are alpha.home and gw.home DNS-able (or in /etc/host) ip addresses    
   (i.e. they are not netgroups or something of that nature)?   
   
gw.home is the DNS server for the home domain. alpha.home and phoenix.home are   
DNS-able and using gw as their only DNS server.   
   
2) The client is either alpha.home or gw.home?   
   
The server is phoenix, alpha is the nfs client on the tests reported. If you   
look at the commands I issued, all command lines starting with "al" are on   
alpha; all command lines starting with "ph" are on phoenix.   
   
3) Does /proc/fs/nfs/exports show all three exports (i.e /home, /home/40g   
   and /home/20g)?   
   
4) Does exportfs -rv talk about exporting things to the kernel   
   (i.e. "exporting alpha.home:/home/40g to kernel")   
 
Yes it did (when I first thought the filesystems weren't exported at all, I 
checked (3) and (4)). You see, the filesystems WERE effectively exported; 
doing the "ls" trick I could always see them on alpha. 
 
It's been more than a year since I had this problem. Phoenix and Alpha are now 
running RH 8.0 and a kernel.org 2.4.21 kernel. The problem no longer exists. 
 
I have two servers (at work) still running RH 7.3 (with nfsutils 0.3.3-5), 
which also had the problem by that time, but they are currently running non-RH 
2.4.21 kernel (and other RH updates), and the problem went away too. This 
means that maybe the problem was not with nfs-utils, but something else. 
 
You mention that your test was with 2.4.18-5smp and nfs-utils 0.3.3-4; I had a 
non-smp kernel, and nfs-utils 0.3.3-5. I don't know if the glibc version would 
matter, but the one I had by that time is also on the report.  
 
Regards, 
 
Joao 

Note You need to log in before you can comment on or make changes to this bug.