We've just replaced a windows file server by one running Linux and are using samba on it. We also have some clients Linux using CIFS and they were using the nocase parameter to get case insensitive file names. This worked perfectly when the file server was still running windows, but now doesn't behave properly anymore when we switched it to Linux.
Samba is also set up to with "case sensitive = no". So we have set it to off on both sides.
What seems to work is to cd into a directory with a different case. Everything else fails, including then trying to open a file in that directory with the correct case, or trying to open dir/file with file in the wrong case but dir in the correct one.
I've also tried it using smbclient and that seems to be working correctly. So I'm guessing that this is a bug in the kernel when the other side supports case sensitive file handling.
Investigating. Is there a particular version of Samba server that you
were using? Also, can you state the exact mount command you do use to
mount samba shares?
The samba server runs Debian's 3.2.5-4lenny8
I believe /etc/fstab looks like contains:
\\server\share /mountpoint cifs username=user,password=pass,uid=user,gid=group,nocase
Atleast that's what I commented out on my laptop, but then with smbfs instead of cifs. I'm pretty sure they use cifs, and I can reproduce it using smbfs too. I'm currently not there and the machines are powered off so I can't remote log in to them. If this is important, I can go and take a look.
No, that is good enough. Whenever you get a chance, you can.
So does this occurr with smbfs as well as cifs?
As far as I know, it happens with both smbfs and cifs.
Could this be a manifestation of difference of handling SMBntcreateX and
SMBopenX in Samba server?
I compared the wireshark traces between cifs vfs client and smbclient
and only difference is NT Create AndX request and Open AndX requests
by cifs vfs client and smbclient respectively, the path names are same
in either cases.
I think SMBopenX handles path names (case) insensitively and SMBntcreateX
does, need to confirm that though.
In case of mount option nocase, cifs vfs client, as it should,
sets the field
Case Sensitivity: Path names are caseless
as 1 in the flag field of the smb header and does not set that
field in case mount option nocase is not specified.
I do not think cifs vfs client can do much beyond that. The
onus is on the server (e.g. Samba) after that to handle such requests.
So you think I should talk to the samba people about this instead?
Can you confirm that you see the problem too?
I do see this issue. I can recreate the problem. I need to verify/confirm
that this is an issue of how Samba server handles Case Sensitivity
(0 for case sensitive and 1 for caseless) bit field in smb header for
NT Create AndX requests and SMB_POSIX_OPEN case, I think it handles it
correctly for Open AndX request (which is what smbclient sends to open a file).
1. load cifs module
2. disable unix extensions (echo 0 > /proc/fs/cifs/LinuxExtensionsEnabled)
3. mount a cifs share with nocase option
and then see whether you can access a file in a case insensitive way?
With POSIX semantics, it overrides Case Sensitivity
Created attachment 25011 [details]
patch to indicate server about file names case sensitivity
Include Case Sensitivity flag in smb header's flag field in case of mount
with nocase option.
This patch is necessary but inspite of this patch, Samba server still fails a
NT Create AndX request for a case insensitive file with an error
This is the error I see on Samba server (the file name on server is File2)
[2010/02/12 13:50:49, 5] smbd/open.c:1525(open_file_ntcreate)
open_file_ntcreate: FILE_OPEN requested for file file2 and file doesn't exist.
[2010/02/12 13:50:49, 5] smbd/files.c:407(file_free)
freed files structure 9535 (0 used)
[2010/02/12 13:50:49, 10] smbd/open.c:3131(create_file_unixpath)
(In reply to comment #9)
> Can you,
> 1. load cifs module
> 2. disable unix extensions (echo 0 > /proc/fs/cifs/LinuxExtensionsEnabled)
> 3. mount a cifs share with nocase option
> and then see whether you can access a file in a case insensitive way?
> With POSIX semantics, it overrides Case Sensitivity
Yes, that fixes the issue for me.
So can you clarify the situation for me? There are more bugs in the kernel? Or there is also a bug in samba?
I do have that option, "case sensitive = no" in smb.conf.
The error happens (object not found) inspite of that.
And case sensitivity bit is set in smb header's Flag field during
requsts such as NT Create AndX (to open a file) such as Tree Connect.
With the patch I posted, Case Sensitivity bit is set during
Tree Connect but that is probably not necessary i.e. that patch
is not needed to overcome this problem.
Kurt, not sure yet. I think it would help if Samba folks can take a
look at this bug and opine.
I've opened a bug in the samba bug tracker:
The Samba setup is broken.
the cifs mount option is about protocol behaviour, the samba setting is about
assumtions that samba should do about the underlying filesystem. So unless you
have JFS created with -O you break your setup when you just set "case
One more thing that baffles me, with linux extensions disabled on
cifs client (i.e. not negotiated with the Samba servr), case insensitivity
works with the same exact Samba server.
I think we need to assign this bug to samba server component.
Would be nice if the observation in comment #16 in samba bugziall bug
7051 is addressed by Samba server folks.
This still happens with samba 3.6.3 in the server side and 3.6.12 in the client side, with both case sensitive = No and nocase.
The problem persist even after disabling unix extensions of cifs module.
Why is this marked as RESOLVED DOCUMENTED?. I don't see this resolved nor documented. I don't see bug 7133 in samba solved either.
And if cifs, with posix semantics, ignores explicit configuration of case sensitivity, isn't that also a bug?
Please don't atttach new bogs to ancient stuff or nobody will even notice it is there.
If you have a bug with a modern kernel then please file a new bug and include the relevant samba versions and smb traces of the transactions.