This problem has existed for quite a while, and I was sticking with 2.2 to work
around it, but 3.0 has been more necessary, lately. (Yes, 2.2 works fine.)
Using SMBD to share a locally mounted NTFS drive displays all directories as a
zero byte file until it is opened, at which time SMBD realizes that it is a
directory and allows navigation.
Mount NTFS drive locally
Share NTFS mount via SMBD
Connect to share from MS File sharing (XP/2K/2K3) or via smbclient
Example via smbclient:
MSDOS.SYS 0 Sun Jun 15 22:32:58 2003
Music 0 Sun Jan 23 17:49:39 2005
NTDETECT.COM 47564 Mon Aug 9 22:15:20 2004
ntldr 250032 Mon Aug 9 22:15:20 2004
smb: \> cd Music
cd \Music\: not a directory
smb: \> get Music
NT_STATUS_FILE_IS_A_DIRECTORY opening remote file \Music
smb: \> cd Music
cd \Music\: not a directory
I've had the same problem on OpenBSD 3.7 with Samba 3.0.14a. It seems like the
problem lies in the NTFS code rather than Samba.
Samba seems to rely on the "number of links" information in the filesystem which
the NTFS driver fails to report.
To get it to work I modified the NTFS code to always report a minimum of 1
number of links and recompiled the kernel.
I did the following modification in the file ntfs_vnops.c on line 232.
vap->va_nlink = ip->i_nlink;
vap->va_nlink = (ip->i_nlink ? ip->i_nlink : 1);
Use this as only a temoprary solution since I don't know how it affects the NTFS
I would say that the problem is definitely with Samba, since 2.2 works fine, and
3.0 doesn't. The OS has no issues with NTFS at all.
You are going to need to get some help from the ntfs
driver folks. I seriously doubt that it is posix compliant.
Or at least give some more evidence to show that the ntfs
driver is giving us the correct info and we a munged it.
Since this is a definite regression in functionality it should at least be
investigated by the Samba team to determine why. If the result is the driver
then at least that information can be taken to the driver team. Since it DID
work and now it doesn't, Samba should investigate why. The only difference is
which version of Samba is installed. 2.2 works, 3.0 doesn't.
Marking this invalid without even investigating is a cop-out.
Would you rather me be honest about the amount
of attention this bug will probably receive
or just leave it open?
If Samba works on posix filesystems such as xfs, etc2/3,
reiser, jfs, ufs, etc....and it doesn't work on NTFS then
you need to get your NTFS developers to run the
posix compliance tests.
The fact that no one else has reported this bug in
over 24 months of 3.0.x releases is an indication
of the pressure from the community to work.
If you have a valid patch that is no full of #ifdef's
then We'll be glad to work accept it. Or if you want
to put on of your NTFS developers in touch with us,
I'll be glad to try to work the bug from that angle.
But asking us to fix a bug without even providing log
files or trace logs? That's just not reasonable.
Sorry. Wish I had better news for you. But I'm just
being honest about the priority of this bug.
I can tell you the problem exactly because of the analysis done by Andreas Wanberg.
Samba uses these macros to determine a valid return from a stat() call for a
file and a directory :
include/smb_macros.h:#define VALID_STAT(st) ((st).st_nlink != 0)
include/smb_macros.h:#define VALID_STAT_OF_DIR(st) (VALID_STAT(st) &&
If your filesystem is returning zero for st_nlink then it's NOT GOING TO WORK.
Your filesystem is broken. Fix it using the patch kindly supplied by Andreas and
re-build your kernel.
This is *NOT* a Samba bug. The reason it worked in 2.x was these macros weren't
being used. They are essential for effieciency and we're not going to pull them
out of Samba just because *you* have a broken POSIX filesystem.
Created attachment 1460 [details]
Ok - having said all that and been nasty (sorry) :-) I really do want to help
and don't like leaving a customer with a broken system. I think the attached
patch will fix the problem for you by solving it in userspace. The filesystem
is still broken though.... I'll leave this up to Jerry if he wants to add it in
as a user-selectable compile-time fix.
Jeremy, do you really think it is a good idea to work around
this bug rather than just gettign the FreeBSD NTFS driver folks
to fix their file system?
I'm assuming the BROKEN_STAT_LINK_COUNT is going to be a
Oh yeah it would be a manual define for broken systems. I'm not so sure I want
to add this code anyway, I just felt really guilty about being nasty to the poor
bloke. I wanted to at least leave him with a working system :-).
I appreciate the code even if it's not going to be integrated. If nothing else,
as I said, it gives me something to go to the driver developers with as fodder.
Does it work ? Does it fix your particular issue ? That's what I'd like to know.
Today was my first chance at testing it, and it does indeed fix the issue in
question. I'm definitely going to forward on the information in this bug to the
BSD driver team.