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 username=etssihs,password=########,nocase 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 customers.
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: 2.6.9-68.8.EL.jtltest.28 ...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 different. Alternately if you could clarify how you're reproducing this it would be helpful. Perhaps I'm doing something different here?
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.
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).
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.
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.
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. --vince Internal Status set to 'Waiting on Support' Status set to: Waiting on Tech This event sent from IssueTracker by vincew issue 163714
Adam, 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. =============== Thanks Jeremy Internal Status set to 'Waiting on Customer' Status set to: Waiting on Client This event sent from IssueTracker by jwest issue 163714
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
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...
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. This event sent from IssueTracker by jwest issue 163714
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.
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
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.