[Samba] Can't access some files

Mon Sep 26 22:09:32 GMT 2005

OS running Samba: FreeBSD 5.4-STABLE amd64
OS accessing Samba: Windows XP SP2
Samba version: samba-3.0.20,1

This is a really frustrating problem.  I've been
dealing with it for a while now, but I recently
upgraded to 3.0.20 in hopes that it would fix it...
and it made it worse.

So first, here is where I expect the problem comes
from.  I've got a 500GB array on the FreeBSD box
("imoen") which is formatted using NTFS.  I don't have
enough hard drive space to back up all the data to
something else and then reformat it using UFS, so
unfortunately I have to make do.  So I'm sure the
problem has to do with the interaction between NTFS
and Samba.  But because this is something that worked
(mostly) in the past, I'm hoping that there might be
some config setting I can change to get it working
again.

The problem is basically that Samba refuses to access
files from this NTFS filesystem.  If I open up the
share on my XP box ("sharwyn"), it shows all the files
in it properly and doesn't give any error messages. 
However, it shows all directories as files.  If I
double-click on one of those
files-that's-really-a-dir, it pops up the Windows "how
do I open this" window, I hit cancel, refresh the
share folder, and now the directory I just selected
shows up as a directory and I can traverse to it.  But
all the other directories - the ones I didn't try to
open - still show up as files.  This appears to be
persistent across restarts of Samba.  Note that from
FreeBSD's perspective, the directories show up just
fine as directories.

The above has been the case since 3.0.16, the last
version I was using.  I got around it by writing a
script to shadow the NTFS directory structure to UFS. 
Basically it would make a tree of directories and
symlinks to files, so something like

  % mkdir -p /shadow/a
  % ln -s /ntfs/a/b /shadow/a/b

This way I would actually have Samba export /shadow
instead of /ntfs, and everything would work great. 
(Except for problem #3, see below.)

Second, if I try to open a file - any file - Samba
claims the file doesn't exist.  Here is the log
message:

[2005/09/26 17:22:11, 5]
smbd/open.c:open_file_ntcreate(1327)
  open_file_ntcreate: FILE_OPEN requested for file
music/you've come a long way, baby/03-in heaven.mp3
and file doesn't exist.

I've also tried on files and directories with no
spaces in the names, same error.  Now if I log onto
imoen and look at the file's data using any tool -
less, file, etc - just like that I can open it from
Samba.  I don't even have to restart Samba, it just
works.

This part has only been happening since I upgraded to
3.0.20.  16 handled it just fine.

Third problem, which happens in both 16 and 20, if I
manage to get Samba to open a file, it spams the
following log messages:

Sep 26 00:00:01 imoen smbd[73451]: [2005/09/26
00:00:01, 0] locking/posix.c:posix_fcntl_lock(659)
Sep 26 00:00:01 imoen smbd[73451]:   posix_fcntl_lock:
WARNING: lock request at offset 7536640, length 32768
returned
Sep 26 00:00:01 imoen smbd[73451]:   an Invalid
argument error. This can happen when using 64 bit lock
offsets
Sep 26 00:00:01 imoen smbd[73451]:   on 32 bit NFS
mounted file systems.

This appears to be relatively harmless, except that it
makes my log files huge because I get about 50 of
these a second and syslogd tanks from all the disk
thrashing.  I include this mainly because it might be
related to the above two problems.  I set "large
readwrite" to "no" which smb.conf(5) suggests might be
the problem, but that has no effect.

I want to stress that I made zero changes to my config
before upgrading.

I did extensive Googling before posting, and there is
one other guy having the same problem (long link):

http://groups.google.com/group/lucky.freebsd.questions/browse_frm/thread/47fc65a04382914e/2383e2d094f222e7?lnk=st&q=samba+%22when+using+64+bit+lock+offsets%22&rnum=24&hl=en#2383e2d094f222e7

but he never seemed to get a resolution.

I can temporarily work around this problem using:

  find /ntfs -type f -print0 | xargs -0 file

but running it on a filesystem with tens of thousands
of files... not exactly fast.  I tried a mere "stat"
but that doesn't work.

I think it's likely this is a FreeBSD-NTFS bug and
that Samba is just the one app that exposes it.  But I
don't have enough info on *what* Samba is doing to
expose the bug to file a useful FreeBSD problem
report.  So even if you can't tell me how to fix the
problem, some insight into what strange fcntls/etc.
Samba is using (that nothing else is) would be a help.
 Or even similar, smaller applications might
demonstrate the same broken behavior so I can come up
with a more manageable testcase.

Thanks!

__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com