Hi,
I am currently on my migration way from raspbmc to osmc. Unfortunately i have an issue with my movie collection located on a remote device mounted via cifs. This worked perfectly with raspbmc and is still doing with the old image and several other systems.
The issue: Certain file located on the remote device can be listed (e.g. just ls), but cannot be accessed (no such file). Only files containing special characters are affected (e.g. colon). Note: there is no such problem on other system with lower kernel version accessing the same remote device. All files do have the same file permissions.
If you want to reproduce:
- mount a device via cifs on a system with kernel < 3.18
- cd to_device; date > “test : test.txt”
- mount this device via cifs on osmc
- cd to_device; ls #this will show the file name
- ls “test : test.txt” # this errors: “no such file”
- cat “test : test.txt” # this errors: “no such file”
Kernel 3.18 seems to have introduced a regression in the cifs fs driver described here: https://bugzilla.kernel.org/show_bug.cgi?id=92401 (There is a downgrade patch attached, a fix seems to be here: [PATCH] Fix that several functions handle incorrect value of mapchars — Linux CIFS Development )
I know this is not a real osmc issue. First of all i would like to get just help in how to work around this problem. I have medium experience in compiling deb-src packages and recompiling kernel modules. Do you think it is an option to to apply one of the mentioned patches? The patch is for 3.18 but osmc is allready on 4.2. Will the patch still work?
One other questions to you osmc liking kernel hackers 
: Why isn’t that bug yet fixed? Is it really just me suffering from this?
Hello
The commit you have linked me to has been included in the upstream kernel (and thus, OSMC) since 10th May 2015. It is upstream commit ID bc8ebdc4f54cc944b0ecc0fb0d18b0ffbaab0468.
I am not sure if there are further regressions. I do not use CIFS but will attempt to replicate this.
Sam
Sorry, this is apparently no bug. From the manpage of mount.cifs:
mapchars
Translate six of the seven reserved characters (not backslash, but
including the colon, question mark, pipe, asterik, greater than and
less than characters) to the remap range (above 0xF000), which also
allows the CIFS client to recognize files created with such
characters by Windows´s POSIX emulation. This can also be useful
when mounting to most versions of Samba (which also forbids
creating and opening files whose names contain any of these seven
characters). This has no effect if the server does not support
Unicode on the wire. Please note that the files created with
mapchars mount option may not be accessible if the share is mounted
without that option.
So the solution in my case is to mount the device with the additional options “nomapchars,nomapposix” under more recent kernels. Sorry for wasting your time. Maybe this will help others 
On the other hand it feels like an bug, because the filenames are listed as usual, but cannot be correctly typed (maybe they can be typed, but not by mouse copy/paste, nor by using autocompletion, even osmc couldn’t play them, because the where stored with ‘standard’ colon, while the filesystem has it with ‘0xFxxx’ ).
If you do it the other way round (create a file “test : test” while mounted with “mapchars,mapposix”, then remount with “nomapchars,nomapposix” and list the files) you will see strange looking filenames…
btw on oscm, my locale is set to “en_US.utf8”, so i don’t quite understand this display issue…