Created attachment 11118 [details] Example of behavior showing old system and new system Recent updates have caused mounted files/directories named with Windows reserved characters (*, :, |, <, >, ?) to behave strangely. Files containing the special characters can be read normally but cannot be deleted. Directories containing the special characters will appear with an `ls` but the contents of the directory will not appear. Files in the directory appear to be readable if the full path is known. The problem is evident with kernel version is 4.0.4-2-ARCH. On an older system (kernel version 3.16.3-1-ARCH) it's fine. I am attaching a file showing some examples of the behavior. Downgrading cifs-utils didn't seem to help. smbclient appears to be unaffected, as I can access the remote server just fine. If it's relevant, I am fairly certain the remote server supports unicode, as I have a number of files on the share that contain CJK characters in filenames (the remote server is the default on the ASUS RT-N66U router). The change seems to have happened in arch sometime between November 2014 and February 2015. I believe this is not an arch-specific bug, as at least one other user has seen the same issue on Debian sid: http://www.reddit.com/r/debian/comments/37pbcq/wildcard_filename_issue_on_cifs_share_under_sid/
I've narrowed down the kernel version this behavior was introduced in, at least in the Arch Linux packages. Version 3.17.6-1-ARCH behaves as expected, but 3.18.2-2-ARCH does not. According to the Arch Rollback Machine, that package was introduced 2015-01-15: http://seblu.net/a/arm/2015/01/15/core/os/x86_64/ So the change was introduced sometime betweer 3.17.6 and 3.18.2. Could it be related to this? https://bugzilla.kernel.org/show_bug.cgi?id=92401 The wiki also says there was a change to the way the reserved characters were mapped: "By default support mapchars ('SFM' style remapping, ie the same way the Mac remaps them) for the seven reserved characters (*, ?, : etc.) when mounting with SMB3." https://wiki.samba.org/index.php/LinuxCIFSKernel#3.18_Kernel
I can confirm this -- I have the same issue. I have a Linux Samba server and Linux client. I believe I am using protocol version 1 (seems to be the default). I changed nothing on the server, but I did upgrade the kernel on my client machine from 3.12.13 to 4.1.12. Since then, I can list but not read files which contain the Windows reserved chars, and I cannot enter directories which contain those chars. Also, since UNIX extensions are enabled on the server and client (this is the default since both are Linux) I cannot use symlinks to read files/directories which have such chars in their paths, even if the symlinks themselves do not have such chars in their names. I use Gentoo Linux on both my client and server. On the client machine, I tried cifs-utils-6.1-r1 and 6.4 -- neither worked. The bug you linked to https://bugzilla.kernel.org/show_bug.cgi?id=92401 describes exactly what I am seeing.
This was resolved and enabled by default for SMB2/SMB3 mounts more than four years ago, but there was this patch which may be important for your use case which certainly should be in by 4.2 kernel. Make sure your /proc/mounts mount entry for this cifs mount shows "mapposix" commit bc8ebdc4f54cc944b0ecc0fb0d18b0ffbaab0468 Author: Nakajima Akira <nakajima.akira@nttcom.co.jp> Date: Fri Feb 13 15:35:58 2015 +0900 Fix that several functions handle incorrect value of mapchars Cifs client has problem with reserved chars filename. [BUG1] : several functions handle incorrect value of mapchars - cifs_sb->mnt_cifs_flags & CIFS_MOUNT_MAP_SPECIAL_CHR); + cifs_remap(cifs_sb)); [BUG2] : forget to convert reserved chars when creating SymbolicLink. - CIFSUnixCreateSymLink() calls cifs_strtoUTF16 + CIFSUnixCreateSymLink() calls cifsConvertToUTF16() with remap [BUG3] : forget to convert reserved chars when getting SymbolicLink. - CIFSSMBUnixQuerySymLink() calls cifs_strtoUTF16 + CIFSSMBUnixQuerySymLink() calls cifsConvertToUTF16() with remap [BUG4] : /proc/mounts don't show "mapposix" when using mapposix mount option + cifs_sb->mnt_cifs_flags & CIFS_MOUNT_MAP_SFM_CHR) + seq_puts(s, ",mapposix");