I recently swapped my aged, provider-given DSL router for a new Asus N17U model. Amongst other stuff, it features 2 USB ports for attaching and sharing mass-storage devices or printers on the network. Last weekend, I found some time to check out how that could serve my needs and stumbled across something I wasn't really prepared for. Here's the story.

I had a spare portable USB disk with some 200 gigs of storage lying around. On purpose, I decided to make it have 3 separate partitions. From previous experience I suspected the router to be unable to handle anything but MBR with FAT32/NTFS on attached drives. That eventually turned-out to be correct. Sigh. Anyway.

I partitioned the drive as MBR, formatted the 3 partitions to use NTFS and hooked it up to the router. Luckily everything worked without any hassle. The router gave enough milliamperes on its port to drive the disk without the need for an additional power supply or Y-USB-cable - and it recognized my intended storage pattern straightaway, giving me 3 "folders" on that disk:

Router shows 3 partitions as sibling folders under root
Fig.1 - How the router sees the drive with its partitions

Next, I learned that I had to create folders in these, eeh, folders, which could then be mapped to access rights and user accounts for sharing. So I did that and finally it looked like this:

Shareable folder needs to be cerated as child of a folder that represents a partition
Fig.2 - A shared folder on partition 2

I was really pleased to see how (relatively) simple that process turned-out to be and set out to actually use the newly created shares.

On Linux

Back to my Ubuntu 16.04 machine, I fired-up its standard graphical file manager (caja in my case) to check if the shares appear. I navigated to the router's IP address using the smb prefix in caja:

smb://192.168.1.3

Strange enough, caja saw the shared folders ...

In the GUI file manager, shares are shown correct
Fig.3 - Shares shown in file manager

but seemed to be unable to access them:
The user/password screen kept popping up to ask for my user and password - just as if I hadn't supplied anything. No error message, nothing.

I sat back, puzzled about what went wrong. Reading the share names again, I suddenly understood: The Asus folks apparently decided to append the respective parent folder's moniker to what I gave as name for the folders. So, as an example, when I created a folder named "pics" on the 2nd partition (provided as "sda2"), the router made it a share under the name of:

pics (at sda2)

I could probably argue about the whys and hows or, even about the WTFs of doing this and put the blame on Asus. But the actual cause of the problem was the fact that I simply overlooked what had happened and what it meant:

Spaces in the share's name.

To see if that was really the cause, I did a quick cross-check by creating a mount point directory as /mnt/foosrv, then a sudo mount on the command-line with the full UNC of the share put into double-quotes.

sudo mount -t cifs "//192.168.1.3/pics (at sda2)" /mnt/foosrv -o username=myusername,password=mypassword,rw

That indeed worked. So the problem seemed to be somewhere with the file manager. Anyway, instead of on-demand access from within a file manager, I rather wanted to have a permanent mount for the share. So I went off to /etc/fstab to append a line using the double-quoted share name. Well, mind you, that didn't work.

Okay, I have to admit that while being an IT professional for more than two decades, I am still a bit of a noob when it comes to Linux. That means that I usually end up having to use Google whenever I run into problems or questions. So here I went again - and I was not only taught that most (GUI-driven) file managers aren't able to grasp the idea of share names with spaces inside them, but moreover, for mounting a share with a space in its name via fstab, I'd need to escape these spaces

With "escaping" the character code of the space (hex 040), the name will look like this:

pics\040(at\040sda2)

So in my case, the line in /etc/fstab had to be:

//192.168.1.3/pics\040(at\040sda2)   /mnt/foosrv    cifs    username=myusername,password=mypassword    0    0

This worked. So far for so good.

On Windows

Out of curiosity, I was wondering how Windows would actually deal with such share names. The only Windows flavor I'm still having at home is a 7 Home inside VirtualBox. And basically, the behaviour was identical. Explorer saw the shares but couldn't connect when double-clicking and submitting credentials. It kept asking me for user and password and told me the share wasn't found.

On the command-line, using the "net" command, I was able to use the same approach as in Linux by wrapping the whole UNC into double-quotes:

net use z: "\\192.168.1.3\pics (at sda2)"

For permanently mapping the share to a drive letter from Explorer, I noticed  a bit of a difference though:
In Explorer, when chosing "map network drive" and wrapping the whole shebang into a pair of double-quotes, there seemed to be some kind of input parsing occuring on the GUI side that evantually made that approach fail. But lo and behold, a little trial-and-error of putting the quotes did the trick:

\\192.168.1.3\"pics (at sda2)"

As you can see, inside Explorer an exact wrap of the "subpath" into double-quotes is required instead of the whole UNC. Nice. Now go and try to explain this to someone who isn't that familiar with computers... *sigh*.
And that is it for the Redmondish Samba flavor.

On LibreELEC (possibly OpenELEC too)

And there is one special case that I was faced with: LibreELEC on my Raspberry Pi. With a strong heritage due to forking, most probably the same is true for OpenELEC (note: I couldn't check in detail).

While the mount on the command-line works just like you would expect from a Linux-based operating system, the special case is with permanently mounting. What makes it special is the fact that with libreelec on the Pi, there is no /etc/fstab.

Well, wait, okay,  there of course is a file named "fstab" in /etc.
But it's empty and isn't used. With LibreELEC on the Pi you use a different way of permanently mounting Samba shares: The "systemd" way I call it. And to my surprise, this one doesn't require you to do any "dirty" tricks around the troublesome share name:

...
[Mount]
What=//192.168.1.3/pics (at sda2)
...

As simple as that. For more details on mounting Samba inside LibreELEC see the according OpenELEC wiki page.

Conclusion

As a summary, here's a little rosetta stone for dealing with spaced share names:

Platform on command line permanent mount
Linux double-quotes for entire UNC

escaped space inside UNC

Windows double-quotes for entire UNC double-quotes around share name
libreelec on Raspberry Pi double-quotes for entire UNC no tricks required

If you stumble across more special cases let me know. I'd be particularly interested to know how things look like -for example- in contemporary Mac OS(X) flavors: Is it like Linux?


Share this post:
Facebooktwittergoogle_pluslinkedinmail

Copyright notice for artwork used on this page (in addition to these):