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 Linux client. 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 fixed.
*** 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 smbfs"? You're not saying *smbmount* is "unmaintained and broken", are you? Also, this bug is *not* a duplicate of 1901. -Rob
Changing the mount type from "smbfs" to "cifs" in the /etc/fstab appears to have fixed this particular problem (and bug 1901). Thanks, -Rob
Of course mount.cifs has its own set of problems, which I'll be creating bugs for. :-( -Rob