From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
Description of problem:
We have mounted samba network drive, and then edit and save a file on
the samba drive the application freezes. The network drive cannot
then be accessed again. Adding files/deleting works ok.
system log error:
Aug 4 08:41:17 ISD-1 kernel: smb_lookup: find //test.xml failed,
Aug 4 08:41:47 ISD-1 kernel: smb_add_request: request [0f4c4080,
mid=422] timed out!
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Open a file on the drive with kwrite
2. Save the file. The application freezes.
3. Mapped drive does not work.
Actual Results: The backup is created, but the new version has zero
Expected Results: New version and backup created/saved, and mapped
drive still accessible.
The samba drive is mounted in rc.local as /mnt/SHARED.
\\as400\home /mnt/SHARED smbfs
user,password=password,uid=500,gid=500,username=as400user,noauto 0 0
what server type is this ? Does cifs work better ?
The mapped drive is on an AS400 IFS, and I have not used cifs. It
was working fine on kernel 2.4 (rh9). Ant build scripts also suffer
the same problem. I did read that kernel 2.6.7 addressed this
Failed to mount /mnt/RUK :
mount error: cifs filesystem not supported by the system
Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)
cifs does not seem to work?
I am also seeing this. My config:
Server: FC2, samba 3.0.7-FC2, kernel 2.6.6-1.435, raid-1 over SATA
Client 1: FC2, samba 3.0.7-FC2, kernel 2.6.8-1.521
Client 2: FC3t2, samba 3.0.7-3, kernel 2.6.8 (stock)
As with Greg, cifs doesn't work for me.
I only started having this issue recently, which as near as I can tell
coincided with upgrading Client 1 to 2.6.8-1.521. This problem did
NOT appear with the 2.6.8 stock kernel I am running on Client 2.
There is at least one other issue with 2.6.8-1.521 that I have seen
(affecting a network driver, apparently unrelated to this problem)
so I don't have high confidence in that kernel build.
When I have a moment, I will regress Client 1 to an older kernel and
see what happens.
Uninstalling 2.6.8-1.521 and rebooting to 2.6.6-1.435.2.3 appears
to have fixed this issue.
("Client 1" in my config is actually a server; it mounts the RAID
volume over SMB and a number of processes use it. So, it exposes
this error within about 15 minutes of uptime.)
It's worth noting that even with the errors with 2.6.8-1.521, the
server on 2.6.6-1.435 *does not* report any errors -- they are
So: RH/Fedora kernels prior to 2.6.8-1.521 do not have this bug in
my environment; stock 2.6.8 does. (My mistake earlier, I checked
I had this problem.
Mounting as CIFS fixed it.
Can you give more info on how mounting the IFS with CIFS was done?
Fedora Core 2 has now reached end of life, and no further updates will be
provided by Red Hat. The Fedora legacy project will be producing further kernel
updates for security problems only.
If this bug has not been fixed in the latest Fedora Core 2 update kernel, please
try to reproduce it under Fedora Core 3, and reopen if necessary, changing the
product version accordingly.