If you happen to live in a Windows/Mac/Linux-environment and you can’t access certain directories ending in spaces or dots, this post is for you. It took me a while to find out what was wrong, when I couldn’t access a couple of directories. I had mounted a Windows Server share on a Linux host. The directories I could not access, had been made on an Apple OSX system and ended in a space or a dot.
Fast forward a dozen of internet searches and the answer lies in a rather obscure mounting option for mount.cifs: mapchars.
The mount.cifs manpage doesn’t explain it all too well, saying:
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.
Uh, what is an asterik exactly? Anyway, there is a bug report from 2015 that shines at least some light on the problem: https://bugzilla.samba.org/show_bug.cgi?id=11206:“mapchars” not handling trailing period and trailing space.
So that is what happens: Macintosh translates a space (0x20 character encoding) to 0xF028, but only if occurring as the last character of the name. Idem for period: 0x2E to 0xF029. Using the “mapchars” option when mounting will have Linux use the same sort of translation.
So if your current Samba mount under Linux does:
mount -t cifs -o iocharset=utf8,credentials=/etc/smbcredentials '\\SERVER\Share' /mnt/
You may want to change that to
mount -t cifs -o iocharset=utf8,credentials=/etc/smbcredentials,mapchars '\\SERVER\Share' /mnt/