Bug 432837
Summary: | Case insensitivity for files on CIFS mounts [RHEL4] | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 4 | Reporter: | Vince Worthington <vincew> | ||||
Component: | kernel | Assignee: | Jeff Layton <jlayton> | ||||
Status: | CLOSED NOTABUG | QA Contact: | Martin Jenner <mjenner> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | high | ||||||
Version: | 4.6 | CC: | jwest, ssorce, steved | ||||
Target Milestone: | rc | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2008-04-08 20:39:44 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Vince Worthington
2008-02-14 17:47:44 UTC
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. |