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: Always 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:
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 without problems.
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] auth/auth_domain.c:domain_client_validate(199) 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. Bryan
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 there. Eric
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 terminal
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 switch. 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.
http://bugme.osdl.org/show_bug.cgi?id=2642 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. so: 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.
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 http://bugme.osdl.org/show_bug.cgi?id=2642 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!