Red Hat Bugzilla – Bug 123895
(FS SMBFS)mounted smb shares cause accessing processes to lock up
Last modified: 2014-08-31 19:26:09 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
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)
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.
A Quick Note ... It does the same thing when connected to a linux box.
Does "dmesg" show any oops messages in this situation
Created attachment 100472 [details]
output of dmesg after mounting a samba share
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
I see the following in my Sys-log after attempting to browse a
smb-server from nautilus:
May 24 09:52:56 bryan smbd: [2004/05/24 09:52:56, 0]
May 24 09:52:56 bryan smbd: 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.
Sorry, I posted my last comment to the wrong bug-list (should've gone
to bug #1239899). Please ignor the comment
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.
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)
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.
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'.
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.
Yup I'm having the same problem with FC2 release; accessing a samba
mounted directory is causing a kernel oops. Things go downhill from
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?
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).
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?
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
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
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
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.
has additional information.
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.
Is there any patch for this bug yet? Seems to me only affect gnome.
Work perfectly ok when I used my xfce4.
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...
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
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.
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.
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.
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!