Bug 11438 - case sensitivity issues over SMB2 or above
Summary: case sensitivity issues over SMB2 or above
Status: RESOLVED FIXED
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.1.13
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Karolin Seeger
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-08-08 04:03 UTC by Paul Smedley
Modified: 2016-05-11 11:32 UTC (History)
3 users (show)

See Also:


Attachments
wireshark logs of port 139 & 445 (15.53 KB, application/x-pcapng)
2015-08-14 09:44 UTC, Paul Smedley
no flags Details
server side log with debug level 10 (439.74 KB, text/plain)
2015-08-14 09:48 UTC, Paul Smedley
no flags Details
server side log with debug level 10 for client PC (133.99 KB, text/plain)
2015-08-15 09:40 UTC, Paul Smedley
no flags Details
possible patch (1.02 KB, patch)
2016-03-18 15:41 UTC, Christian Ambach
no flags Details
proposed patch (1.26 KB, patch)
2016-05-01 12:40 UTC, Christian Ambach
no flags Details
git-am fix for 4.4.next, 4.3.next. (5.60 KB, patch)
2016-05-04 20:41 UTC, Jeremy Allison
ambi: review+
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Smedley 2015-08-08 04:03:30 UTC
Problems exist with listing directories using case insensitive names over SMB2 or above.

I have a folder called 'Desktop' in a share called Public on my Samba server running on Ubuntu.

Using SMB3, trying to list the directory fails if I use the case-insensitive name.

psmedley@XPS13:~$ smbclient //192.168.1.200/Public -mSMB3 -d 10 --username=psmedley -N 2> smbclient.log
Anonymous login successful

smb: \> 
smb: \> ls desktop
NT_STATUS_NO_SUCH_FILE listing \desktop
smb: \> ls Desktop
  Desktop                             D        0  Mon Jul 20 13:51:45 2015

		-1366264008 blocks of size 1024. -1997689408 blocks available
smb: \> exit

Using SMB1, running ls with the case-insensitive name works fine.
psmedley@XPS13:~$ smbclient //192.168.1.200/Public -d 10 --username=psmedley -N 2> smbclient.log
Anonymous login successful
smb: \> ls desktop
  Desktop                             D        0  Mon Jul 20 13:51:45 2015

		65535 blocks of size 33553920. 65535 blocks available

This occurs with 'case sensitive' set to auto or no in smb.conf

I see the same behaviour with Samba 4.2.3 built on OS/2.
Comment 1 Paul Smedley 2015-08-08 08:40:05 UTC
I just tested with -mSMB2 and it seems to work OK, so perhaps it's just a problem with SMB3?
Comment 2 Paul Smedley 2015-08-08 09:54:20 UTC
Also tested with 4.3.0rc2 on linux and same behaviour
Comment 3 Richard Sharpe 2015-08-13 14:42:42 UTC
Can you get us:

1. A capture of the on-the-wire behavior, and

2. A level 10 log of the activity on the server for that client?
Comment 4 Paul Smedley 2015-08-14 09:44:44 UTC
Created attachment 11333 [details]
wireshark logs of port 139 & 445

I've never used wireshark before, but I've attempted to capture traffic over ports 139 and 445. 

The client commands were:
smbclient //192.168.1.200/Public -mSMB3 --username=psmedley -N

'cd desktop'

smbclient returned:
cd \desktop\: NT_STATUS_OBJECT_NAME_NOT_FOUND
Comment 5 Paul Smedley 2015-08-14 09:48:57 UTC
Created attachment 11334 [details]
server side log with debug level 10

Server side logs attached as requested
Comment 6 Paul Smedley 2015-08-15 09:40:31 UTC
Created attachment 11336 [details]
server side log with debug level 10 for client PC
Comment 7 Paul Smedley 2015-08-22 09:29:30 UTC
I tested from a Windows 7 command line, and things seem to work OK. I'm assuming that Windows 7 would be connecting via SMB >= 2 by default. Would server side / wireshark logs from Windows 7 be of any assistance?
Comment 8 Christian Ambach 2016-02-27 14:02:57 UTC
Looks like a SMB2 create request is always case-sensitive, ignoring the smb.conf setting.
Have to do more code digging to find out how to fix this.
Comment 9 Christian Ambach 2016-03-18 15:41:02 UTC
Created attachment 11929 [details]
possible patch

Can you give this patch a try?
Comment 10 Paul Smedley 2016-04-28 11:37:51 UTC
Hi Christian, apologies for the delay. Correct me if I'm wrong, this appears to be a server side patch? Changing this file doesn't result in any changes for smbclient.
Comment 11 Christian Ambach 2016-05-01 12:40:02 UTC
Created attachment 12054 [details]
proposed patch

Hi Paul,

correct, this is a server side patch. There is nothing wrong about the behavior of smbclient.
In the meanwhile, I have prepared a better patch that also covers the rename scenario.
Are you able to try it out?
Comment 12 Paul Smedley 2016-05-02 11:56:02 UTC
@Lewis - are you able to try a build with this patch on your OpenSuse install? If not, I'll try get it built here
Comment 13 Lewis Rosenthal 2016-05-02 15:57:19 UTC
(In reply to Paul Smedley from comment #12)

I finally got my build box back up and running (after a bumpy upgrade from 13.2 to Leap 42.1). I should be able to look at building this sometime this week.

I did think that I saw this same behavior when connecting to a Windows share, so I am skeptical that this is *all* of the fix for this particular condition, but let's start here, as Christian was kind enough to provide the patch.
Comment 14 Jeremy Allison 2016-05-04 20:41:38 UTC
Created attachment 12064 [details]
git-am fix for 4.4.next, 4.3.next.
Comment 15 Christian Ambach 2016-05-05 11:43:46 UTC
(In reply to Jeremy Allison from comment #14)

Why not add the patch with the test as well?
Comment 16 Jeremy Allison 2016-05-05 17:37:47 UTC
(In reply to Christian Ambach from comment #15)

Doesn't cleanly apply as the test env has changed. If you want to back-port it I'll review, but it's not necessary for the fix.
Comment 17 Christian Ambach 2016-05-06 12:58:24 UTC
Hi Karolin,

please pick for 4.3.x and 4.4.x.
Comment 18 Karolin Seeger 2016-05-09 08:09:45 UTC
(In reply to Christian Ambach from comment #17)
Pushed to autobuild-v4-[3|4]-test.
Comment 19 Karolin Seeger 2016-05-11 11:32:43 UTC
(In reply to Karolin Seeger from comment #18)
Pushed to both branches.
Closing out bug report.

Thanks!