Bug 15130 - nocase doesn't work when talking to a samba server
Summary: nocase doesn't work when talking to a samba server
Status: RESOLVED DOCUMENTED
Alias: None
Product: File System
Classification: Unclassified
Component: CIFS (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: fs_cifs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-01-24 20:24 UTC by Kurt Roeckx
Modified: 2014-05-15 16:53 UTC (History)
4 users (show)

See Also:
Kernel Version: 2.6.32
Tree: Mainline
Regression: No


Attachments
patch to indicate server about file names case sensitivity (807 bytes, patch)
2010-02-12 18:20 UTC, Shirish Pargaonkar
Details | Diff

Description Kurt Roeckx 2010-01-24 20:24:15 UTC
Hi,

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.


Kurt
Comment 1 Shirish Pargaonkar 2010-02-04 19:16:12 UTC
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?
Comment 2 Kurt Roeckx 2010-02-04 19:46:15 UTC
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.


Kurt
Comment 3 Shirish Pargaonkar 2010-02-04 20:29:29 UTC
No, that is good enough. Whenever you get a chance, you can.
So does this occurr with smbfs as well as cifs?
Comment 4 Kurt Roeckx 2010-02-04 20:52:25 UTC
As far as I know, it happens with both smbfs and cifs.
Comment 5 Shirish Pargaonkar 2010-02-04 23:27:39 UTC
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.
Investigating further.
Comment 6 Shirish Pargaonkar 2010-02-05 17:25:50 UTC
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.
Comment 7 Kurt Roeckx 2010-02-05 17:35:04 UTC
So you think I should talk to the samba people about this instead?

Can you confirm that you see the problem too?
Comment 8 Shirish Pargaonkar 2010-02-05 17:43:45 UTC
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).
Comment 9 Shirish Pargaonkar 2010-02-08 22:02:44 UTC
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
Comment 10 Shirish Pargaonkar 2010-02-12 18:20:15 UTC
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.
Comment 11 Shirish Pargaonkar 2010-02-12 18:26:32 UTC
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  
object_not_found.
Comment 12 Shirish Pargaonkar 2010-02-12 19:58:56 UTC
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)
  create_file_unixpath: NT_STATUS_OBJECT_NAME_NOT_FOUND
Comment 13 Kurt Roeckx 2010-02-13 17:53:39 UTC
(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.
Comment 14 Kurt Roeckx 2010-02-13 17:55:34 UTC
So can you clarify the situation for me?  There are more bugs in the kernel?  Or there is also a bug in samba?
Comment 15 Shirish Pargaonkar 2010-02-14 14:58:15 UTC
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.
Comment 16 Kurt Roeckx 2010-02-14 16:03:50 UTC
I've opened a bug in the samba bug tracker:
https://bugzilla.samba.org/show_bug.cgi?id=7133
Comment 17 Björn Jacke 2010-02-15 09:46:28 UTC
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
sensitive=no".
Comment 18 Shirish Pargaonkar 2010-02-15 12:09:43 UTC
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.
Comment 19 Shirish Pargaonkar 2010-03-30 18:50:29 UTC
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.
Comment 20 Senen de Diego 2014-05-14 18:29:10 UTC
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?
Comment 21 Alan 2014-05-15 16:53:32 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.