I boxed this one in, but don't know where to dig deeper. Basically a smb share automounted before we switched to daylight time was returning strange inconsistent timestamps. $ stat /foo/bar/1856.txt File: `/foo/bar/1856.txt' Size: 0 Blocks: 0 IO Block: 4096 Regular File Device: ah/10d Inode: 17964 Links: 1 Access: (0664/-rw-rw-r--) Uid: ( 0/ root) Gid: ( 703/ ptlc) Access: 2004-04-06 19:56:40.000000000 -0700 Modify: 2004-04-06 19:56:40.000000000 -0700 Change: 2004-04-06 19:56:40.000000000 -0700 $ stat /foo/bar/* File: `/foo/bar/1856.txt' Size: 0 Blocks: 0 IO Block: 4096 Regular File Device: ah/10d Inode: 17964 Links: 1 Access: (0664/-rw-rw-r--) Uid: ( 0/ root) Gid: ( 703/ ptlc) Access: 2004-04-06 18:56:39.000000000 -0700 Modify: 2004-04-06 18:56:39.000000000 -0700 Change: 2004-04-06 18:56:39.000000000 -0700 Strange huh? Timestamp in the future when no glob. Here are the details. # cat /etc/auto.master /foo /etc/auto.foo --timeout=600 # cat /etc/auto.foo bar - fstype=smbfs,rw,gid=bozo,fmask=0664,username=dork,password=bjork ://se rver/share The work-around was to force a remount of the share. And yes, it's been continually in use since Saturday, so no auto umount timeout.
This is a kernel problem (in the smbfs kernel module), rather than a Samba one. I'm reassigning it to the kernel maintainers. In the mean time, you might try Fedora Core 2 test 2. The 2.6 kernel comes with the cifs kernel module, which has active maintainers.
Thanks for the bug report. However, Red Hat no longer maintains this version of the product. Please upgrade to the latest version and open a new bug if the problem persists. The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, and if you believe this bug is interesting to them, please report the problem in the bug tracker at: http://bugzilla.fedora.us/