Description of problem: A share on a Windows XP Professional computer on a network is mounted from a fully updated (as of January 29, 2005) Fedora Core 3 i386 installation. Version-Release number of selected component (if applicable): samba.i386 3.0.10-1.fc3 How reproducible: 1. mount -t cifs //computername/shared_directory . or mount -t smbfs //computername/shared_directory . 2. Use emacs, or some other editor, to repeatedly modify a text file located in the shared directory. Actual results: This has been repeatedly verified several times, before and after clean boots of all networked machines. After a certain number of "writes" of the file, where a "write" is opening of a file, writing to it, and then closing it (this certain number has been found to be always < 50, sometimes much less, < 5), the share "disappears". I say "disappear", because the disconnect is not clean, i.e. instead of disconnecting and allowing you to re-connect using the aforementioned mount commands, it bogs down the last write when it happens, and locks up the application performing it. Eventually, the app may, or may not, go past the lock up, but there's no going back to normal operation after the first lock up. Expected results: No disconnection or disappearance of the shared directory. Additional info: This is a real problem. The machine that has Fedora Core 3 on it dual (or triple) boots FreeBSD 5.3 and also Windows XP Professional. The network share in question that is located on a second machine running Windows XP Professional, *never* disconnects or disappears if it has been mounted from the Fedora 3/FreeBSD 5.3/Windows XP machine. That there are absolutely no problems with samba under FreeBSD 5.3 on the same machine is notable.
Clarification: *never* disconnects or disappears if it has been mounted from the Fedora 3/FreeBSD 5.3/Windows XP machine when Windows XP or FreeBSD has been booted.
Once the mount succeeds, all the userspace programs that are part of the samba-* packages ane out of the picture. This must be a kernel problem. I'm reassigning this to the correct maintainer.
Thank you. The kernel is the latest released officially for Fedora 3 i386 via up2date. It is 2.6.10-1.741_FC3smp.
This is to keep you up-to-date on what happens -- the problem continues with the latest kernel (2.6.10-1.760_FC3smp) and all the other updates. I stand by the accuracy of all my words up to now. I would also like to add that sometimes even SMB read accesses lock up apps. So, for now, FreeBSD 5.3 is the way to go...
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which may contain a fix for your problem. Please update to this new kernel, and report whether or not it fixes your problem. If you have updated to Fedora Core 4 since this bug was opened, and the problem still occurs with the latest updates for that release, please change the version field of this bug to 'fc4'. Thank you.
I just updated to the latest kernel, the one you quote (and other packages, although I don't remember to have seen samba recently in the yum update list). I specifically booted with the non-SMP kernel and did everything as described previously. Same story -- it happens after a lot less than 50 saves. Also I should note that the remote disk's filesystem (NTFS) is sometimes corrupted by this happening, although the corruption is fixable. It could be a very unpleasant surprise to someone. I say sometimes, because there was no corruption this time (just hanging), but 1-2 months ago I re-tested the problem on my own initiative and I did get corruption. Fortunately, I have Fedora Core 4 running under QEMU under Fedora Core 3. I'll test with it, too, and report back.
Under a fully updated Fedora Core 4 (running under QEMU as mentioned above, and with the QEMU kqemu kernel acceleration module loaded), and latest Fedora Core 4 kernel booted, the lockup occurred on the very first save! Not only that, but the Fedora Core 4 system totally froze after about a minute (it was running the default Gnome desktop). Going out of that meant just closing QEMU, of course. No filesystem corruption has been found on the remote computer afterwards (XP Pro on it has been also fully updated beforehand, too). That indeed must be a kernel issue, and so it is present on both Fedora Core 3 and 4. Regarding the machine, it is rock stable with everything, and a couple of days ago its BIOS was upgraded to the latest one currently supplied by the motherboard manufacturer (ASUS). It is a P5GD1-VM system (i915G chipset). I hope the above info will eventually be of some help.
As you advised, I have changed the OS version field to FC4. I'd leave to you if anything else needs to be done to indicate that the error is present in FC3 as well.
Mass update to all FC4 bugs: An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream kernel (2.6.13.2). As there were ~3500 changes upstream between this and the previous kernel, it's possible your bug has been fixed already. Please retest with this update, and update this bug if necessary. Thanks.
2.6.14-1.1637_FC4 has been released as an update for FC4. Please retest with this update, as a large amount of code has been changed in this release, which may have fixed your problem. Thank you.
Hello, Fixed! Kernel 2.6.14-1.1637_FC4 under Fedora Core 4 has fixed the problem. Kernel 2.6.12-1.1381_FC3smp under Fedora Core 3 has fixed the problem, too (should this be noted somewhere else for Fedora Core 3 /I know it is EOL'd/?). Thank you! Best regards, Vesselin.
actually FC3 is still supported (though I dont think for much longer).