Bug 2794 - Samba shares of mounted NTFS file systems display directories as zero byte files
Samba shares of mounted NTFS file systems display directories as zero byte files
Product: Samba 3.0
Classification: Unclassified
Component: File Services
x86 FreeBSD
: P3 normal
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2005-06-13 11:09 UTC by Jay Rossiter
Modified: 2005-10-05 18:47 UTC (History)
0 users

See Also:

Proposed patch (943 bytes, patch)
2005-09-27 19:41 UTC, Jeremy Allison
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jay Rossiter 2005-06-13 11:09:54 UTC
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
Comment 1 Andreas Wanberg 2005-08-01 07:22:45 UTC
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
Comment 2 Jay Rossiter 2005-08-01 10:48:23 UTC
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.
Comment 3 Gerald (Jerry) Carter 2005-09-27 13:55:19 UTC
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.
Comment 4 Jay Rossiter 2005-09-27 14:05:34 UTC
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.
Comment 5 Gerald (Jerry) Carter 2005-09-27 14:27:15 UTC
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.
Comment 6 Jeremy Allison 2005-09-27 14:29:36 UTC
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.

Comment 7 Jeremy Allison 2005-09-27 19:41:19 UTC
Created attachment 1460 [details]
Proposed patch

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.
Comment 8 Gerald (Jerry) Carter 2005-09-28 07:51:13 UTC
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 
manual #define.
Comment 9 Jeremy Allison 2005-09-28 09:28:11 UTC
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 :-).
Comment 10 Jay Rossiter 2005-09-28 10:39:19 UTC
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.
Comment 11 Jeremy Allison 2005-09-28 10:46:08 UTC
Does it work ? Does it fix your particular issue ? That's what I'd like to know.
Comment 12 Jay Rossiter 2005-10-05 18:47:53 UTC
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.