Bug 89589 - smbmount not returning after mount
smbmount not returning after mount
Status: CLOSED CANTFIX
Product: Red Hat Linux
Classification: Retired
Component: samba (Show other bugs)
9
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jay Fenlason
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-04-24 13:55 EDT by Paul Rensing
Modified: 2014-08-31 19:24 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-02 13:32:10 EST
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 Paul Rensing 2003-04-24 13:55:16 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.6 (X11; Linux i686; U;) Gecko/20020830

Description of problem:
I have autofs setup to automount some Samba shares. It stopped working when
going from RH8.0 to RH9. The problem is that /bin/mount (which is called by
autofs) is mangle the options when calling mount.smbfs. Using "ps", I could
discover the calls that were being made (because mount.smbfs is hanging waiting
for a password). Autofs calls mount like this:

/bin/mount -t smbfs -s -o username=guest,guest,fmask=0777,dmask=0777
//gigadrive1/public /mnt/smb/gigadrive1

This results in the call:

/sbin/mount.smbfs //gigadrive1/public /mnt/smb/gigadrive1 -o rw username guest
guest fmask 0777 dmask 0777

Notice that all the commas and equal signs of the option string have been
stripped out. The result is that mount.smbfs does not correctly parse its
options, and it hangs.

Version-Release number of selected component (if applicable):
mount-2.11y-9

How reproducible:
Always

Steps to Reproduce:
1. setup autofs to point to a Samba share
2. restart autofs
3. cd into the Samba filesystem
    

Additional info:
Comment 1 Paul Rensing 2003-06-05 14:57:04 EDT
Actually, I was wrong when I first described this problem, but it is still a bug. 

The problem is that smbmount hangs (but not always). I have watched it happen a
few times. smbmount forks into two processes. The second process is detached
from the pty and does the mount. It is meant to stay running as long as the SMB
filesystem is mounted. This all seems to work. 

The problem appears to be that the original smbmount process hangs after
spawning the "worker" process. I can fix it by "kill -9" the original process,
but that is yuchy.

BTW, this does not require automount. It does seem to have something to do with
not requiring a password.  I run the command like:

mount -t smbfs //gigadrive2/public /mnt/tmp -o guest,fmask=0777,dmask=0777

   Paul Rensing
Comment 2 Target 2003-07-07 16:24:53 EDT
I filed Bug 97743 after running a search and not finding this bug.

The problem is nearly identical, and matches the findings here. smbmount never
locked up for me when used manually because I was using -o
username=foo,password=bar.

The automatic or fstab-aided mount attempts here use the "credentials" option
pointing to files with usernames & passwords, and these exhibit the lockup very
often. I can also confirm that smbmount locks up often when logging in as guest
via ftsab entry.
Comment 3 Markus Bertheau 2003-08-06 05:21:13 EDT
I have the same problem with three mounts from a Windows 2000 box:

[root@fluor root]# ps aux | grep mount
root      2354  0.0  0.6  4688 1532 ?        S    11:08   0:00 /sbin/mount.smbfs
//server2000/Entwicklung /mnt/entwicklung -o rw noexec nosuid nodev noauto user
username m.bertheau gid 500 password XXXXXXXXX uid 1000 fmask 664 iocharset utf8
codepage cp850
root      2359  0.0  0.5  4688 1528 ?        S    11:08   0:00 /sbin/mount.smbfs
//server2000/Mitarbeiter /mnt/mitarbeiter -o rw noexec nosuid nodev noauto user
username m.bertheau gid 500 password XXXXXXXXX uid 1000 fmask 664 iocharset utf8
codepage cp850
root      2361  0.0  0.2  3472  548 pts/0    S    11:08   0:00 mount infobrett/
root      2362  0.0  0.5  4684 1408 pts/0    S    11:08   0:00 /sbin/mount.smbfs
//server2000/INFOBRETT /mnt/infobrett -o rw noexec nosuid nodev noauto user
username m.bertheau gid 500 password XXXXXXXXX uid 1000 fmask 664 iocharset utf8
codepage cp850
root      2363  0.0  0.5  4684 1348 ?        S    11:08   0:00 /sbin/mount.smbfs
//server2000/INFOBRETT /mnt/infobrett -o rw noexec nosuid nodev noauto user
username m.bertheau gid 500 password XXXXXXXXX uid 1000 fmask 664 iocharset utf8
codepage cp850
root      2476  0.0  0.2  3636  692 pts/1    S    11:09   0:00 grep mount
[root@fluor root]#

This is after mounting them manually on the commandline with fstab help. The
first to succeeded, the third mount hangs. The filesystem is perfectly
accessible though.

I had previously a gentoo box at work, my colleague a RedHat 7.3 (or 7.2, don't
know) box, both did not exhibit this behaviour. Now both run RedHat 9 and both
exhibit the problem.
Comment 4 Scott Moorhouse 2003-08-11 13:14:45 EDT
I am experiencing the same behavior as above.  It started only after install of
Red Hat 9.

Curiously, it returns fine when I su to do the mount, but hangs when I su - or
run it out of root's cron.

Comment 5 Pádraig Brady 2003-09-09 09:44:18 EDT
Me also. Only started with Redhat 9.
Usually fstab entries hang, but
very rarely a manual mount also hangs up.
I straced and the mount parent was
hung in wait4() and the forked child
was (mount.smbfs) was also pause()ing ?
Seems like a deadlock that is easy to
trigger with fstab entries to me.
Comment 6 John Franks 2003-09-13 10:47:53 EDT
This bit me too.  I don't think it has anything to do with automount or fstab. 
Sometimes the choice of "su" versus "su -" seems to affect the frequency, but
that is probably just superstitious behavior.

I tried it with samba-2.2.7a-8.9.0 and with samba-3.0.0-5rc1 from rawhide. 
There was no difference.

As a workaround I have been doing

     #!/bin/sh

     smbmount <whatever> &
     sleep 5
     kill $!

Has anyone found something better.
Comment 7 Karl schmidt 2003-09-17 22:37:24 EDT
Having the same problem after 'upgrading' to RH9. 

My samba scripts quit running - running by had I got:

[root@malaysia mnt]# smbmount //singapore/backups $SINGMNT/backups/ $SMB
INFO: Debug class all level = 2   (pid 9510 from pid 9510)
added interface ip=192.168.1.200 bcast=192.168.1.255 nmask=255.255.255.0

at which point it hangs - but not always!

Has anyone tried going back to samba-2.2.5-10?


I also found this bug referenced at:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=3f04587e%240%2443849%2439cecf19%40news.twtelecom.net&rnum=4&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3D3f04587e%25240%252443849%252439cecf19%2540news.twtelecom.net%26rnum%3D4



 
Comment 8 Paul Rensing 2003-09-18 16:39:47 EDT
Here is a slightly improved hack. 

Move /usr/bin/smbmount to /usr/bin/smbmount.orig. Then create the following
script as /usr/bin/smbmount:

-------------------------
#!/bin/sh

/usr/bin/smbmount.orig $* &
proc=$!

for i in `seq 1 5`; do
    sleep 1
    if mount | grep -q $1; then
	kill -9 $proc
	exit
    fi
done

kill -9 $proc
-------------------------
This as a little lower lag time then simply waiting 5 seconds.

As for the bug, I wonder if it has more to do with the new version of gcc and
glibc (with threads) then with the actually samba code. I know I tried using the
smbmount executable from RH8 (without recompiling), but it did not work.
Comment 9 Ben Ross 2003-09-25 21:41:47 EDT
I am also seeing this bug on RH 9, but not RH 8. I was originally using smbmount
2.2.7a-security-rollup-fix but also tried smbmount 2.2.8a (from a samba RPM) and
the same thing occurs.

I tend to agree that this problem is probably more due to a new glibc & gcc
rather than samba (or smbfs), as the randomness suggests a race-condition.
Comment 10 arch harris 2003-10-02 09:46:29 EDT
I experience the problem using the "smbmount" command.  I have added
debugging statements and after the child process terminates, the parent
executes a "pause" command, waiting for a SIGUSR1 signal from "smbfs".
That signal never appears to arrive.
Comment 11 arch harris 2003-10-02 13:20:10 EDT
BUG WORKAROUND! This appears to be a race condition problem.  I do not know but
I suspect killing the process may have other undesirable consequences (particular
if the mount legitimately fails for example becuase the server is unavailable).

I have a bug workaround for the source code that appears to eliminate a race
condition.

In the source code for smbmount, I added a "sleep(1);" just after the call
to "sys_fork" in func "init_mount" (this is around line 478).  This has (so far)
eliminated the problem.  I am using version 2.2.7a
Comment 12 Bill Nottingham 2006-08-04 23:32:25 EDT
Red Hat apologizes that these issues have not been resolved yet. We do want to
make sure that no important bugs slip through the cracks.

Red Hat Linux 7.3 and Red Hat Linux 9 are no longer supported by Red Hat, Inc.
They are maintained by the Fedora Legacy project (http://www.fedoralegacy.org/)
for security updates only. If this is a security issue, please reassign to the
'Fedora Legacy' product in bugzilla. Please note that Legacy security update
support for these products will stop on December 31st, 2006.

If this is not a security issue, please check if this issue is still present
in a current Fedora Core release. If so, please change the product and version
to match, and check the box indicating that the requested information has been
provided.

If you are currently still running Red Hat Linux 7.3 or 9, please note that
Fedora Legacy security update support for these products will stop on December
31st, 2006. You are strongly advised to upgrade to a current Fedora Core release
or Red Hat Enterprise Linux or comparable. Some information on which option may
be right for you is available at http://www.redhat.com/rhel/migrate/redhatlinux/.

Any bug still open against Red Hat Linux 7.3 or 9 at the end of 2006 will be
closed 'CANTFIX'. Again, if this bug still exists in a current release, or is a
security issue, please change the product as necessary. We thank you for your
help, and apologize again that we haven't handled these issues to this point.
Comment 14 Bill Nottingham 2007-01-02 13:32:10 EST
Red Hat Linux 7.3 and Red Hat Linux 9 are no longer supported by Red Hat, Inc.
f you are currently still running Red Hat Linux 7.3 or 9, you are strongly
advised to upgrade to a current Fedora Core release or Red Hat Enterprise Linux
or comparable. Some information on which option may be right for you is
available at http://www.redhat.com/rhel/migrate/redhatlinux/.

Closing as CANTFIX.

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