I've only seen this behavior since upgrading from RedHat Linux 9 (and an older
version of Samba) to Fedora Core 2 (and Samba/smbmount v3.0.7):
Using a multi-threaded application (http://www.synchro.net) that access files
exclusively in an smbfs-mounted directory, many of the files that are opened
and closed in rapid succession (e.g. configuration and data files), often
simultaneously by multiple threads, are sometimes left in an "exclusive open"
state on the file server. Running "lsof" on the Linux client does not list the
open files and the application thinks it has closed the files successfully,
yet they appear in the 'open files' list on the Windows 2000 file server. Even
terminating the application does not close the files on the file server. The
file will forever remain in this zombie "open" state until the file(s) are
manually closed on the file server (using Computer Management->System Tools-
>Shared Folders->Open Files) or the smbfs-mounted directory is unmounted on the
This problem has only been seen with multi-threaded applications and is a
relatively new one (to either Linux or smbmount). Single-threaded
implementations of the same programs do not exhibit this problem.
please use cifs. smbfs is unmaintained and broken. If you see a bug when using
cifs please open a bug for that, there is a much better chance that that will be
*** Bug 1901 has been marked as a duplicate of this bug. ***
Can you please elaborate?
Is there some other smbmount syntax that should be used in place of "mount -t
You're not saying *smbmount* is "unmaintained and broken", are you?
Also, this bug is *not* a duplicate of 1901.
Changing the mount type from "smbfs" to "cifs" in the /etc/fstab appears to
have fixed this particular problem (and bug 1901).
Of course mount.cifs has its own set of problems, which I'll be creating bugs