Bug 432837 - Case insensitivity for files on CIFS mounts [RHEL4]
Case insensitivity for files on CIFS mounts [RHEL4]
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
high Severity high
: rc
: ---
Assigned To: Jeff Layton
Martin Jenner
Depends On:
  Show dependency treegraph
Reported: 2008-02-14 12:47 EST by Vince Worthington
Modified: 2014-06-18 03:37 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-04-08 16:39:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
capture of reproducer (984 bytes, patch)
2008-02-15 13:28 EST, Jeff Layton
no flags Details | Diff

  None (edit)
Description Vince Worthington 2008-02-14 12:47:44 EST
Customer Name:   IBM Burlington
Customer RH Login:   etsslx2

Description of problem:
Customer needs cifs mounts to be case insensitive.  He has found that if they
use the "nocase" option when mounting a cifs filesystem, they get case
insensitivity for directory related commands, but all file operations fail (such
as open).

How reproducible:

Export shares as case insensitive from Samba server (or windows server) and
mount them using CIFS.  Attempt to access files using mixed case filenames.

Steps to Reproduce:

Samba "shares" exported as case insensitive and then mounted as CIFS file
systems on Linux clients.

They mount the filesystem using an fstab entry of:

//etsslx3/proddb        /etssdata/bepl/prod       cifs 

When the ls command is used, you can list the file in various ways:                 

The file as it resides on the file/Samba server -                       
[wjsldap@etsslx3a pro]$ ls -lart nikonil.nam                           

-rw-rw-r--  1 jreynold cmdpro 13343 Oct 12  2006 nikonil.nam            

[wjsldap@etsslx3a pro]$ ls -lart nikonil.NAM                           

ls: nikonil.NAM: No such file or directory                              

The file as it resides on a Linux client, CIFS mounting the Samba case
insensitive share -                                                     
[root@dteihs1 pro]# ls -lart nikonil.nam                                
-rw-rw-r--  1 jreynold cmdpro 13343 Oct 12  2006 nikonil.nam            

[root@dteihs1 pro]# ls -lart nikonil.NAM                                
-rw-rw-r--  1 jreynold cmdpro 13343 Oct 12  2006 nikonil.NAM            

If we edit the file using vi -                                          
[root@dteihs1 pro]# vi nikonil.NAM                                      
"nikonil.NAM" [Permission Denied]                                       
(no file content and the silly message)                                 

[root@dteihs1 pro]# vi nikonil.nam                                      
(see file content just fine)

Actual results:

Files cannot be opened using case insensitive names.

Expected results:

Since AIX clients and Windows clients are able to open files using case
insentivity, the customer feels CIFS under Linux should as well.  

Additional info:

The latest version of CIFS (v1.50) does not contain any code that would provide
case insensitivity on file opens, so this functionality is not available in
newer releases.  There are obvious problems that arise from implementing this
functionality regarding shell wildcard expansion/regular expression processing,
but the fact that other OSes do support this (AIX and Windows) led the customer
to believe it should be done here as well.  

Customer's Business Case:

The IBM Burlington manufacturing facility has written several million dollars
worth of application code that runs the semiconductor manufacturing process that
directly generates several million dollars of revenue for the IBM corporation.
The application code is being ported from OS/2 to Linux and the CIFS case
insensitivity support is required to minimize the cost of the port and the cost
of missing logic that would be in error due to a case sensitivity issue. Missing
logic for case sensitivity would cause scrap in the manufacturing line resulting
in lost revenue and a damaged reputation for the IBM corporation with external
Comment 2 Jeff Layton 2008-02-15 13:07:18 EST
I can't seem to reproduce this. I exported a share from samba and set this on it:

   case sensitive = no

...and then touched a file in that share on the server:

   # touch nikonil.nam

...I then mounted it up via CIFS from a RHEL4 client with the nocase option and did:

   # ls -l /mnt/cifs/nikonil.NAM
   -rw-r--r--  1 root root 0 Feb 15 13:01 /mnt/cifs/nikonil.NAM

...seems to work for me. I'm testing with the test kernels on my people page though:


...it's possible this is something that's already fixed there. You may want to
have them test those kernels someplace non-critical and see if the behavior is

Alternately if you could clarify how you're reproducing this it would be
helpful. Perhaps I'm doing something different here?
Comment 3 Jeff Layton 2008-02-15 13:13:46 EST
Ahh my bad...I misread the above. I do see an ENOENT returned on open. cifsFYI
shows this:

 fs/cifs/file.c:  inode = 0x000001001b08e070 file flags are 0x8000 for /nikonil.NAM
 fs/cifs/transport.c: For smb_command 162
 fs/cifs/transport.c: Sending smb of length 110
 fs/cifs/connect.c: rfc1002 length 0x27)
Status code returned 0xc0000034 NT_STATUS_OBJECT_NAME_NOT_FOUND
 fs/cifs/netmisc.c:  !!Mapping smb error code 2 to POSIX err -2 !!
 fs/cifs/cifssmb.c: Error in Open = -2

...so it looks like the server is returning the error here. I'll need to look a
bit more closely at some captures though. Perhaps it's inadvertently setting the
case sensitive flag or something.
Comment 4 Jeff Layton 2008-02-15 13:28:25 EST
Created attachment 295026 [details]
capture of reproducer

This is starting to look more like a samba problem. When I do:

# cat /mnt/cifs/nikonil.NAM

...I see a QueryPathInfo call go out on the wire for that name. That succeeds,
but then the CreateAndX call against the same name then fails. I've got "case
sensitive" set to no for the share and am mounting with nocase. When I look at
the capture I see the case sensitive bit is set (which wireshark says actually
means that it's case insensitive).
Comment 6 Jeff Layton 2008-02-15 14:39:17 EST
After talking with Simo it sounds like when you have unix extensions enabled
that case sensitivity is mandated. So if they disable unix extensions on the
server it should make this work for them as expected. In samba, setting this in
the global section should do it:

    unix extensions = no

> IBM states that this also happens when mounting shares from a windows server.

Not in my experience. This worked fine for me against a Win2k3 server. If that's
what they're seeing then ask them for a way to reproduce this.
Comment 7 Jeff Layton 2008-02-15 14:40:15 EST
Setting to NEEDINFO. Let me know if they can provide a way to reproduce this
problem against windows or against a samba server with unix extensions disabled.
Comment 8 Issue Tracker 2008-02-15 15:00:56 EST
Thanks Jeff.  I'm seeing the same thing here against 3.0.25b with the
latest released RHEL 4 kernel on the cifs client.  Disabling unix
extensions in samba makes it operate case-insensitively on files.  Opening
existing files in any mixture of case opens the file successfully.


Internal Status set to 'Waiting on Support'
Status set to: Waiting on Tech

This event sent from IssueTracker by vincew 
 issue 163714
Comment 12 Issue Tracker 2008-04-07 16:24:38 EDT

Here's another update from engineering:

Also with regard to the customer needing to reboot after changing the
samba configuration - did they still have the shares mounted by the cifs
clients?  The information they gave us suggests they umounted/remounted
already.  If so, they probably need to unload the cifs module as well
(once any mounts using it have been unmounted).  I'm pretty sure that
would be sufficient, rather than having to reboot.


Internal Status set to 'Waiting on Customer'
Status set to: Waiting on Client

This event sent from IssueTracker by jwest 
 issue 163714
Comment 13 Issue Tracker 2008-04-07 16:24:40 EDT
I thought about that, and I suspect that it would work.  The problem is
that the machine in question also mounts filesystem from other servers. 
In order to recycle cifs, it would require all cifs mounts to be brought
down.  Since working with files within the CIFS mounts is the primary
function of the customer's client machines, this would in effect be the
same as a reboot (although perhaps a bit faster).

It seems very buggy that changing the "unix extensions" setting on a
server causes all clients to have to unmount all cifs mounts to all
servers and remount.

Internal Status set to 'Waiting on Support'
Status set to: Waiting on Tech

This event sent from IssueTracker by jwest 
 issue 163714
Comment 14 Jeff Layton 2008-04-08 09:26:01 EDT
Ok. There's really very little we can do here -- the client is already doing all
it can for case-insensitivity. It's just that its requests are being ignored by
the server because POSIX extensions override it.

I think we only have 2 possible outcomes:

1) add a note to the manpage that "nocase" is indeed only a request and the
server may not honor it. In particular, most samba servers ignore this request
if posix extensions are enabled.

2) transition this to a samba bug and try to make the case that case
insensitivity and posix shouldn't be mutually exclusive. This will probably be a
very difficult sell, however and would certainly need to go upstream.

My suggestion would be #1...

Comment 15 Issue Tracker 2008-04-08 10:53:22 EDT
I think there is some confusion about the current status of this problem. 
I don't believe the customer is hitting a case insensitivity bug here.

The problem I reported in my update on 3/24 was pointing out the problem
the customer had when they made this change.  When they change "unix
extensions = no" on the Samba server, their CIFS clients are either no
longer able to mount the share (the mount error 20 I reported) or the
mount is successful, but they cannot access the mountpoint afterwards (the
"Not a directory" error).  They later found out that rebooting the client
fixed this problem, but this will cause significant downtime for them to
reboot all of their application machines (hundreds of them), plus it
doesn't make any sense.  Why would changing a parameter on the server
force the client to be rebooted?  Obviously the mount would have to be
unmounted and remounted, but that should be it.  It appears that either
CIFS is broken here.

After a client machine is rebooted, it is able to mount the shares again,
and case insensitivity works as expected.

As far as your two points:

1.  In this case, the customer was setting "case sensitive = no" and
"unix extensions = no" on the Samba server, so it should not have been
ignoring the request.

2.  The customer is not upset by the fact that "unix extensions" and
"case sensitive" have to be used together.  It would have been nice if
the manpage mentioned this prerequisite, but there is no desire from the
customer to remove the dependency.

The only remaining question on this issue is why does CIFS fail to mount
the share correctly after the server changes it's settings?  I attached a
cifsFYI of one of the failure cases on 3/26 to hopefully help shed light on

This event sent from IssueTracker by jwest 
 issue 163714
Comment 16 Jeff Layton 2008-04-08 11:31:49 EDT
I'm afraid that your 3/24 update never made it to the BZ...

> The only remaining question on this issue is why does CIFS fail to mount
> the share correctly after the server changes it's settings?

CIFS simply isn't equipped to handle the situation where POSIX extensions are
enabled on the server and then suddenly disabled. This probably could be done,
but it's not a common situation and not something I see us spending time trying
to address.

The decision about whether to use POSIX extensions is made at session setup
time, and sessions are shared when possible. I know of no server that presents
some shares with posix extensions and some without, so it's reasonable to assume
that if you have existing mounts that allow posix extensions then other mounts
utilizing the same SMB session should assume they're available.

IOW, turning off unix extensions while hosts have active mounts is not something
I'd consider "supported". If you wish to turn off unix extensions on the server
then you'll need to plan to remount the shares.
Comment 17 Issue Tracker 2008-04-08 12:20:38 EDT
That makes sense.  The customer did remount the shares (that was when they
had the problem) but I can't say for certain that there were no other
shares mounted from the same server at the time.

Are you saying then that if the customer were to unmount all shares from
the server, then change the posix extensions parameter, and remount all of
the filesystems, there shouldn't be any problem?  If all mounts are
removed from that particular server, I would think that the next mount
would do a session setup and see the new parameter.

The idea here is to get around the reboot or cifs module reload.

Internal Status set to 'Waiting on Support'
Status set to: Waiting on Tech

This event sent from IssueTracker by jwest 
 issue 163714
Comment 18 Jeff Layton 2008-04-08 12:29:07 EDT
Yes, I believe that should work.

I've never tested this however, so I'm going on knowledge of the code. You may
want to test it out yourself before recommending it.

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