Bug 88841 - mount smbfs frequently hangs
Summary: mount smbfs frequently hangs
Keywords:
Status: CLOSED DUPLICATE of bug 90036
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: samba
Version: 9
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jay Fenlason
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-04-14 19:53 UTC by Alexander Keusch
Modified: 2014-08-31 23:24 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-02-21 18:52:40 UTC
Embargoed:


Attachments (Terms of Use)

Description Alexander Keusch 2003-04-14 19:53:01 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.3) Gecko/20030313

Description of problem:
while mounting a drive from a other samba server the mount command often hangs
(nearly every 2nd mount).
that looks so:
i run "mount -a -t smbfs" and some drives get mountet until it hangs at drive
(but this drive where mount hangs also get mounted).

ps -ax says at this time:

4938 pts/1    S      0:00 mount -a -t smbfs
4939 pts/1    S      0:00 /sbin/mount.smbfs //192.168.0.1/MP3s /mnt/server/mp3s
4940 ?        S      0:00 /sbin/mount.smbfs //192.168.0.1/MP3s /mnt/server/mp3s

aborting with "Ctrl+C" works, all dirves which were mountet until the it hangs
stay mountet (in this case /mnt/server/mp3s).

the same problem appears while booting.
here it also hangs at mounting the smb filesystems. but i can't abort with
"Ctrl+C" only a reboot works.

the entrys in my fstab look like this:

//192.168.0.1/MP3s           /mnt/server/mp3s        smbfs
uid=500,gid=501,password="" 0 0


Version-Release number of selected component (if applicable):


How reproducible:
Sometimes

Steps to Reproduce:
1. mount -a -t smbfs

Actual Results:  the command hangs

Expected Results:  the command should terminate

Additional info:

i'm using all avaliable updates (samba-client-2.2.7a-8.9.0 and kernel-2.4.20-9)

Comment 1 Need Real Name 2003-04-14 23:29:40 UTC
Can confirm I'm seeing this in RedHat Linux 9. I'm adding my comment here as I
can't add it to bug #82820, although isn't this a duplicate of that bug? 
Please, if it is a dupe, don't close this until that bug can be added to: it
currently says the following when I try and add to it:

 You tried to change the component field from AfterStep-APPS to
 mount, but only the owner or submitter of the bug, or a sufficiently
 empowered user, may change that field.

As to the samba problem itself: in my case the server isn't an MS box, it's a
RedHat 7.3 machine with kernel 2.4.18-27.7.x, samba 2.2.7-2.7.3.  The 
Shrike machine is the client, and it sometimes
mounts and sometimes won't mount smb shares from the server (they just
hang but are ^C-able).  The ^C leaves a mount.smbfs process in defunct
state, but which is kill -9'able.  Client config: kernel 2.4.20-8,
samba-client 2.2.7a-7.9.0, pending update.
                                                                                
I didn't test Phoebe, but this wasn't and isn't present in 8.0 or
7.*. clients: they're still happily mounting multiple shares from the
same server.
                                                                                
Sorry, but it's really hard to provide a test case here, as the
problem comes and goes, but hangs more than not, so the problem is
serious.  It seems to be more frequently reproduced when I try to
mount via automount entries, but I've seen it hang often also from
manual mounts.  Most commonly, I seem to see the second mount request
hanging after a first one completed ok to a different share on the
same server.  I'm using the credentials, uid and gid options to
mount.
                                                                                
Would any other diagnostic information be useful?  Too many unknown
variables and not enough reproducability for me here...
                                                                                


Comment 2 fred-m 2003-04-18 08:59:14 UTC
I am having the same problem and found a workaround. Suspecting that it could be
a problem with NPTL, I did "setenv LD_ASSUME_KERNEL 2.4.1", and after that
smbmount never hanged anymore.

Here is some more information for anyone who tries to debug smbmount. The tail
of the output of smbmount with debug=65536 is:

...
2030: session setup ok
write_socket(3,73)
write_socket(3,73) wrote 73
got smb length of 49
size=49
smb_com=0x75
smb_rcls=0
smb_reh=0
smb_err=0
smb_flg=136
smb_flg2=1
smb_tid=2048
smb_pid=2030
smb_uid=2048
smb_mid=1
smt_wct=3
smb_vwv[0]=255 (0xFF)
smb_vwv[1]=49 (0x31)
smb_vwv[2]=1 (0x1)
smb_bcc=8
[000] 41 3A 00 4E 54 46 53 00                           A:.NTFS. 
2030: tconx ok

It hangs at this point. The "ps ax" output shows:

 2030 pts/1    S      0:00 smbmount //sirius/sync-home /mnt/sync-home -o debug 6
 2031 ?        S      0:00 smbmount //sirius/sync-home /mnt/sync-home -o debug 6

(Since this can be a timing problem: the machine is a 566 MHz Celeron).

Comment 3 Michael Olson 2003-04-23 16:53:26 UTC
I can confirm this on RH9 in a mixed Linux/WinNT/2000 environment. There seems
to be no way of predicting when it will hang. Sometimes everytime, sometimes
once out of maybe 10 or 20 mounts. Problem does not occur on a RH7.2 box I have
laying around.

After Control-C ing out of mount command I can access the mount point with no
problem. I tried setting LD_ASSUME_KERNEL to 2.4.1 as suggested in comment #2
with no luck.


Comment 4 Alexander Keusch 2003-04-23 18:16:11 UTC
i tryed setting LD_ASSUME_KERNEL to 2.4.1 and 2.2.5 and it also didn't work for me.

Comment 5 Tomas Mraz 2003-04-28 14:04:41 UTC
Confirming here too (against NT 4 server).


Comment 6 Justin Georgeson 2003-04-28 15:21:04 UTC
i have it too, RH 9, fully up2date, Win 2K Pro SP2

Comment 7 Jay Fenlason 2003-05-01 15:16:21 UTC
We've traced this down to a bug in glibc.  At the request of one of the glibc
maintainers, I've opened a new bug against glibc for it.  I'm going to mark all
these smbmount bugs as duplicates of the new bug.

*** This bug has been marked as a duplicate of 90036 ***

Comment 8 Red Hat Bugzilla 2006-02-21 18:52:40 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.


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