Bug 89589

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

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.

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.

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.

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.

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.

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



 

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.

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.

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.

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

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.

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.