Hi, We have a share setup with a lot of files in 1 directory. We force everything to lower case with the following options: default case = lower case sensitive = True preserve case = no short preserve case = no Normally you should be able to access the files in both lower and upper case, but this only works if you set "max protocol = NT1". If you set it to SMB2 or higher, you get "File not found" if you try to access the files in upper case. If you do the same test on a share with only a few files in it, it works for all protocols. I have tested this on samba 3.6.9, 4.0.0 and 4.1.8 and they all behave in the same way. Best regards,
Ok, I'm going to need more data on a reproducible test case. When you say: "If you do the same test on a share with only a few files in it, it works for all protocols." but then: "If you set it to SMB2 or higher, you get "File not found" if you try to access the files in upper case." this doesn't give me enough information to even begin to look at this. Firstly - give me a script or something that will reproduce the file list you have in the directory you're examining. Secondly, tell me *exactly* how you're "try(ing) to access the files in upper case." What client ? What mechanism ? I'll need debug level 10 logs plus a wireshark trace showing the problem. The easiest way for me to discover the bug and fix it is if you can reproduce it using smbclient (not a Windows client). Thanks, Jeremy.
Created attachment 10018 [details] Debug logs, smd.conf and dir listing
Hi Jeremy, I've attached a directory listing of the share that I use, together with a tcpdump and debug log of what happens if I list the file in uppercase. You can set this up by "zcat | xargs touch"'ing the directory listing and setting up a share like the attached smb.conf. If you then issue an ls with smbclient, you'll get the different behaviour between SMB2 and NT1: The expected behaviour with NT1 i.e. Both lower and upper case return a result: 14:42:59|root@test:~ 0 # smbclient //sambaserver/testbigdir -d 0 -U xxxxx -W RTO -c 'ls _DRR001A5C8B.MP3' -mNT1 Domain=[RTO] OS=[Unix] Server=[Samba 4.1.8] _drr001a5c8b.mp3 N 0 Tue Jun 10 11:55:03 2014 64506 blocks of size 32768. 57516 blocks available 14:53:40|root@test:~ 0 # smbclient //sambaserver/testbigdir -d 0 -U xxxxx -W RTO -c 'ls _drr001a5c8b.mp3' -mNT1 Domain=[RTO] OS=[Unix] Server=[Samba 4.1.8] _drr001a5c8b.mp3 N 0 Tue Jun 10 11:55:03 2014 64506 blocks of size 32768. 57516 blocks available With SMB2 you you get 'No such file' with uppercase filenames: 14:54:10|root@test:~ 0 # smbclient //cic-gpfsstag1tb.servers.dmf.be/testbigdir -d 0 -U xxxxx -W RTO -c 'ls _DRR001A5C8B.MP3' -mSMB2 Domain=[RTO] OS=[] Server=[] NT_STATUS_NO_SUCH_FILE listing \_DRR001A5C8B.MP3 14:58:18|root@test:~ 0 # smbclient //cic-gpfsstag1tb.servers.dmf.be/testbigdir -d 0 -U xxxxx -W RTO -c 'ls _drr001a5c8b.mp3' -mSMB2 Domain=[RTO] OS=[] Server=[] _drr001a5c8b.mp3 N 0 Tue Jun 10 11:55:03 2014 2064208 blocks of size 1024. 1840524 blocks available
Ok, reproduced it and I see the bug. In the SMB1 case we're going through filename_convert() with the entire passed in path (directory + wildcard). That does the name case normalization strnorm() on the last component in the path if it doesn't contain a wildcard. This step isn't being done in the SMB2/3 case. We've never noticed before as I think a Windows client only ever sends '*' for the pathname to search. Give me a bit, and I'll fix it. Jeremy.
Created attachment 10020 [details] git-am fix for master/4.1.next/4.0.next. Fixes the bug for me. Please test and report back. Thanks ! Jeremy.
Hi, I've tested the patch and it now works as expected. Thanks for fixing this so quickly ! Best regards, Ben
Comment on attachment 10020 [details] git-am fix for master/4.1.next/4.0.next. For 4.0 and 4.1 this is probably okay. For master please take a look at the additional patches I posted to samba-technical
Re-assigning to Karolin for inclusion in 4.1.next, 4.0.next. Jeremy.
Created attachment 10052 [details] v3-6-test backport of that patch Jeremy, I know, we are not going to address this for 3.6.x anymore, but can you quickly check if the backport looks allright ?
Comment on attachment 10052 [details] v3-6-test backport of that patch LGTM.
Thanks Jeremy :)
Assigning to Karolin for inclusion.
Pushed to autobuild-v4-[0|1]-test.
Pushed to both branches. Closing out bug report. Thanks!