Hello all. I am trying to figure out an smbfs issue. My company stores email directories on a Win2K Server (SP2), with two email servers (Red Hat 7.1, kernel 2.4.9-34) accessing the share. Email messages are stored in independent files within these directories (we use the "Maildir" format). For a few days last week, one specific email directory had a curious problem where the last (most recent) file in the directory became seemingly "locked;" any attempt to move or rename the file resulted in error messages like these: mv: cannot unlink `1030570088.21768.server1,S=655@2,': Text file busy mv: cannot remove `1030570088.21768.server1,S=655@2,': Text file busy A strange thing is, when another message file entered this directory, the lock problem passed on to that file; the original file was then "unlocked," but the new file was "locked." Even stranger was that this problem only appeared on one of the servers accessing the smbfs share. If I tried moving or renaming the file using the second server, the lock problem cleared up temporarily; the file could then be freely moved or renamed from either server, but later on the problem would reappear with whatever the last file was in the directory, at that point. There are no user programs that access these files from the Windows side, and the programs that access the files via smbfs do not use any kind of locking (I have verified this either with documentation or other information provided by the program authors). Does anybody know of anything in the smbfs code for kernel 2.4.9 that could be causing this, and what I might do to prevent it? The server that was experiencing this problem was decommissioned at the end of last week (for other reasons), so I am currently not seeing this problem. However, I want to make sure this doesn't happen again. If more info is needed, or if I should ask this question in a different forum (I have already tried the Samba mailing list), please let me know. Thanks! ---Kris Kelley - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html