Red Hat Bugzilla – Bug 146535
Mounted SMB share "disappears" after a number of file writes in the share
Last modified: 2015-01-04 17:16:21 EST
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
Version-Release number of selected component (if applicable):
1. mount -t cifs //computername/shared_directory .
mount -t smbfs //computername/shared_directory .
2. Use emacs, or some other editor, to repeatedly modify a text file
located in the shared directory.
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.
No disconnection or disappearance of the shared directory.
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'.
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
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
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
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 (220.127.116.11). 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.
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.
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/?).
actually FC3 is still supported (though I dont think for much longer).