Bug 123895 - (FS SMBFS)mounted smb shares cause accessing processes to lock up
(FS SMBFS)mounted smb shares cause accessing processes to lock up
Product: Fedora
Classification: Fedora
Component: samba (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Jay Fenlason
Depends On:
  Show dependency treegraph
Reported: 2004-05-21 09:42 EDT by Bryan Cole
Modified: 2014-08-31 19:26 EDT (History)
16 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-10-28 13:14:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
output of dmesg after mounting a samba share (15.03 KB, text/plain)
2004-05-23 04:13 EDT, Alexander Keusch
no flags Details
Kernel Error after smb mount (2.24 KB, text/plain)
2004-05-24 10:32 EDT, Jorge Adrian Salaices
no flags Details

  None (edit)
Description Bryan Cole 2004-05-21 09:42:04 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.5 (X11; Linux i686; U;) Gecko/20020618

Description of problem:
when mounting a smb-share (on a Win2000 Server) using smbmount (or
mount.smbfs etc.), smbmount executes OK, but when I cd to the mounted
directory, the terminal hangs. 

Also, in gnome, nautilus dies when trying to access the mounted share.
I've not found a way to restore nautilus operation or kill the
smbmount process. A reboot appears to be the only way to restore
normal operation AFAICS

This issue is new to FC2. I've seen reports than samba versions
<=3.0.2a work OK in this respect.

Version-Release number of selected component (if applicable):
samba-3.0.3 and 3.0.4

How reproducible:

Steps to Reproduce:
1. as root, attempt to mount a Windows share using smbmount
2. cd to the mounted directory in a shell
3. see the shell lock up! (and soon after this, nautilus dies)proce

Actual Results:  processes trying to access the share lock up.
A normal shutdown fails when trying to umount the share. 
A "hard" reboot (plug out power plug) is necessary!

Expected Results:  normal file-system access to the shared drive (or a
sensible error message indicating why no access was possible)

Additional info:
Comment 1 Tom Morton 2004-05-21 14:33:17 EDT
I'm running into the same issue.  Interestingly, If you mount a second
share igoring the first share which is hung, then the second share
will mount correctly and be accessible without issue. 
Comment 2 Jorge Adrian Salaices 2004-05-21 17:11:34 EDT
A Quick Note ... It does the same thing when connected to a linux box.
Comment 3 Alan Cox 2004-05-21 18:44:27 EDT
Does "dmesg" show any oops messages in this situation
Comment 4 Alexander Keusch 2004-05-23 04:13:28 EDT
Created attachment 100472 [details]
output of dmesg after mounting a samba share
Comment 5 Alexander Keusch 2004-05-23 04:48:37 EDT
I've made some tests now:

This problem only seems to appear if Gnome (Nautilus?) is runnig while
the share gets mounted.
If no user is logged in and the mount is done from tty1 there is no
problem. It's also possible to start Gnome after the drive is mounted
without problems.
Comment 6 Bryan Cole 2004-05-24 05:03:24 EDT
I see the following in my Sys-log after attempting to browse a
smb-server from nautilus:

May 24 09:52:56 bryan smbd[31179]: [2004/05/24 09:52:56, 0]
May 24 09:52:56 bryan smbd[31179]:   domain_client_validate: unable to
validate password for user Vinny in domain TERAVIEWHQ to Domain
controller \\TERAVIEW-W2KS1. Error was NT_STATUS_NO_SUCH_USER. 

Now the question is ... who the hell is Vinny?????????????????????
(it's not me or anyone else in this company by the way)

Looks like someone has hard-coded a user name, perhaps.

Comment 7 Bryan Cole 2004-05-24 05:15:33 EDT
Sorry, I posted my last comment to the wrong bug-list (should've gone
to bug #1239899). Please ignor the comment
Comment 8 Jorge Adrian Salaices 2004-05-24 10:32:45 EDT
Created attachment 100498 [details]
Kernel Error after smb mount

This is what comes out on the syslog after you mount a share to a Linux box.
Comment 9 Ronald van Kuijk 2004-05-24 11:45:33 EDT
Same happens here with this kernel (2.6.5-1.358) and a previous one
(2.6.5-1.327) I'll try a 2.6.4 kernel in a minute.

I cannot even shut the system down. umount says al normal mounts (like
/opt, /home ) are also busy... strange. I have to physically switch
the system off (lucky me I run a journalling filesystem)
Comment 10 Ronald van Kuijk 2004-05-24 12:05:39 EDT
btw, samba on my laptop where the problem occures is 3.0.2a-1.1, samba
on the server is 2.2.x (5 I think). Since my laptop is running
'production' I cannot give it a try to downgrade it to a "fedora core
2 test 1" where I'm pretty sure have seen it working.
Comment 11 Steve Brown 2004-05-25 11:29:26 EDT
I did a combination of actions including removing and recreating the
share (on the Windows 2000 machine), rebooting both machines and
mounting the drive while using XFCE as my GUI instead of KDE.  I'm not
sure what worked, but the drive seems to be mounted fine now.  I even
went back to KDE, unmounted it and remounted it.

Also, I ran yum just prior to getting it to work, but the only thing
it seemed to update was 'dbh'.
Comment 12 Alexander Kain 2004-05-26 01:25:57 EDT
This might be the solution:

I went to init 3, and I mounted my smbfs share. No problem. So, I
thought the problem was with GNOME. I init 5, and I did a 'mount' in a
terminal to see whether it was still mounted. It was, and additionally
I saw the following line:

sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)\

then it dawned on me that I turned off all the rpc* services for init
5. Hmm, I thought maybe those are needed, especially since one of
these is still running ;) and in the past we needed smbd+friends also
... So I re-added all rpc* services to init 5 and now I can mount and
unmount all I want.

The mistake was to prune these new services (rpc*) before REALLY
knowing what they were, even though they only advertised themselves as
relating to NFS4. Let's add the word "samba" somewhere, especially to
rpcidmapd which seems to be core required service.
Comment 13 Eric Meyers 2004-05-26 10:39:16 EDT
Yup I'm having the same problem with FC2 release; accessing a samba 
mounted directory is causing a kernel oops. Things go downhill from 

Comment 14 Ronald van Kuijk 2004-05-26 17:34:17 EDT
I to stopped rpcidmapd for runlevel 5 a few weeks ago, but adding it
again does not solve it for me. Still nog success. The 2 other rpc
services (with gss do not start since I have no nfs running). Which
services should all be running to use smbfs?
Comment 15 Alexander Kain 2004-05-26 17:48:06 EDT
I tried again: I rebooted, and this time all rpc* services were
started (and rpcidmapd was actually running) and at runlevel 5 I
mounted a share, and accessed it via double-clicking the desktop-icon,
upon which nautilus crashed, the kernel oopsed, umounting wasn't
possible. If I mount on runlevel 3, everything works great from there
on (including remounting the share in level 5).
Comment 16 Alexander Kain 2004-05-26 18:00:35 EDT
And again: This time I did a clean reboot. Logged into XFCE and
mounting and unmounting worked fine the first time. Afterwards, GNOME
worked ok. It seems like mounting a smbfs share the first time within
GNOME is the problem. Can somebody verify this?
Comment 17 Ronald van Kuijk 2004-05-26 18:18:05 EDT
Confirmed. I did a reboot, into runlevel 5 but a 'safe xterm' (from
gdm) instead of GNOME. Mounted the share, exited and logged into GNOME. 

Now I can see the content of the share, either via Nautilus or via a
Comment 18 Ronald van Kuijk 2004-05-26 18:22:37 EDT
One of the differences I see in /var/log/messages is that gnome tries
to find \\.Trash-<uid> when mounting the share from within gnome.
Could that have something to do with it? I do not see that if the
share is mounted outside of gnome
Comment 19 Chris Schultz 2004-05-26 19:40:47 EDT
Further info.  Connect via ssh while console in init 5 (waiting for a
user to log in) can mount a share and navigate into it fine.  The same
fails when a user is logged into Gnome.

I can unmount the mount point using

umount -l /mnt/point

and can then reboot/halt happily
Comment 20 Ken Z 2004-06-01 10:41:15 EDT
Yes it does appear to be related to running Gnome. 
I have tried this on two FC-2 systems with identical results. One 
attaches to Linux - smb server, the other to a Windows server. If the 
client system user is logged into gnome, then the smb mount fails on 
the first attempt from a cold start every single time. On these 
systems, smbmount and smbumount are running with sudo for the user. 
If you try to cd to the directory, then the gnome desktop terminal 
session hangs. Other mounts to other shares afterwards seem to work 
just fine. The system shutdown will hang trying to unmount the 
dead/failed directory node. I have to slap it down with the power 
On the other hand...  
If I boot from cold start and log into KDE, then I do not see this 
problem. The first mount is successful in this case using KDE. 
Comment 21 Alexander Kain 2004-06-02 01:09:59 EDT

has additional information.
Comment 22 Tom Morton 2004-06-03 11:15:24 EDT
Thanks for that info.  The end of that discussion has a work around
(that I'm a hppily using) which I'll re-post here:

------- Additional Comment #16 From Tom Mraz  2004-05-19 02:06 -------

Workaround is to call killall -STOP nautilus before mounting the fs
and -CONT after.

Comment 23 radon 2004-06-12 12:26:16 EDT
Is there any patch for this bug yet? Seems to me only affect gnome.
Work perfectly ok when I used my xfce4.
Comment 24 Ronald van Kuijk 2004-06-14 10:48:40 EDT
I recently upgraded fedora core 2 with some experimental versions of
gnome, nautlius etc.. from
http://people.ecsc.co.uk/~matt/repository.html and still had the
problem and upgrading to kernel 2.6.6-1 also is no solution... 

Comment 25 Chris Hall 2004-06-15 13:03:40 EDT
Just my $0.02.  after installing the latest kernel package 2.6.6-1.435
from 2.6.6-1.427, i noticed this problem.  mounting seemed to work ok
but trying to ls the mounted dir locked the terminal and shutdown
would not finish because the mounted dir was "busy".  luckily i still
had the 2.6.6-1.427 kernel package installed so after rebooting using
the 427 kernel, i went directly to the console and tried mounting the
shared window dir again.  this time it worked.  i have another fc2 box
running the 2.6.5-1.358 kernel package and it also works with no
problem.  so it appears to me to possibly be related to the
2.6.6-1.435 kernel package.


2.6.5-1.358 - works
2.6.6-1.427 - works
2.6.6-1.435 - broken

note: all the kernels are stock packages, i have not recompiled any of
the kernels.
Comment 26 Chris Hall 2004-06-15 13:36:53 EDT
please disregard my comments.  i should have read all the other
comments before even posting and even then, i still didn't spend
nearly enough time researching the problem.

everything in my post is incorrect so please ignore it.  i apologize
for  wasting everyone's time with my erroneous information.

Comment 27 Rob Lanphier 2004-06-25 17:22:54 EDT
Appears to be fixed in Linux kernel 2.6.7-rc3 and later

I haven't tried upgrading yet, but the "killall -STOP nautilus before
mounting the fs and -CONT after" workaround works for me.
Comment 28 Matthew Miller 2005-04-26 11:39:01 EDT
Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.
Comment 29 John Thacker 2006-10-28 13:14:13 EDT
Note that FC1 and FC2 are no longer supported even by Fedora Legacy.  Many
changes have occurred since these older releases.  Please install a supported
version of Fedora Core and retest.  If this still occurs on FC3 or FC4, please
assign to that version and Fedora Legacy.  If it still occurs on FC5 or FC6,
please reopen and assign to the correct version.  Thanks!

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