This is a service post that, like many before it, is meant to mostly leave a note to myself on how to do something that took me a while to sort out, and also possibly provide a breadcrumb for others, assuming that search engines manage to throw out the algorithmically generated SEO spam.
A Little Context: Home Assistant NAS Support
The most recent Home Assistant release as of me writing this, 2023.6 has introduced support for network-attached storage, to hold media and backups, both of which were interesting options for me.
For backups up to now I had been backing up on the eMMC of my Odroid N2 and then fetching this from the Gamestation to back it up to an external drive with Acronis. I know that there are options to use Google Drive instead, but that would require leaving Drive’s credentials on the Home Assistant device and I wasn’t really keen on it.
Being able to access media outside of the storage available on the Home Assistant device is also quite interesting given what I was thinking about in terms of accessing music on CD that does not exist on Spotify. While I have not started making use of this in any meaningful way, I do like keeping that option open for the future.
While media is (not unexpectedly) available read-only to guests on the local network (how else would I be playing it on the TV?), for backups Home Assistant clearly needs write access. And while I trust Home Assistant a lot, I thought it would be a better idea to not just give it full access to the rest of my NAS where backups and other important files are.
Thankfully, Home Assistant allow configuring different network storage locations for different use cases. Unlike Kodi (and, for the most part, Windows) that has you defining the access (hostname, user, and password) before accessing specific shares, it looks like Home Assistant defines everything attached to the location, which was a bit surprising, but only a little bit.
Given that I wanted to have a specific share where HA would be writing its backups and that’s all. This is generally straightforward in TrueNAS — but I also didn’t want to pollute my network browser with showing this additional share for every user connecting (not that there’s many, it’s basically just me, my wife, and a couple of automation users.) That turned out annoying.
TrueNAS, Samba, and Bad Documentation
My friend Alex gave me his old FreeNAS Mini a few months ago, because it stopped working reliably after a power surge in his flat. To the surprise of none of us, the problem turned out to be the power supply — though ixSystems uses an annoyingly rare power supply format called Flex ATX, so while replacing the power supply shouldn’t have been difficult, it require figuring out a power supply that would work for the job (I settled for SilverStone FX350-G because Scan Computers had it available) and then cutting through the metal on the back of the chassis, as there was no cutout for the power switch of the supply!
Since I’m still uncomfortable to the idea of using ZFS on Linux (call me old fashioned), I decided to use TrueNAS Core (based on FreeBSD), and it seems to be working basically fine. The main use case for this has been sharing the media files for various content that we watch with Kodi on the TV, but it also makes for a much easier way to share data with VMs and other development environments. All in all, not bad.
Unfortunately I have found that TrueNAS’s documentation is quite lacking and not really something I’d like to work with on a regular basis. In many cases, including the one I’m going to be talking about here, they appear to mostly try to repeat some of the documentation coming from whichever upstream project they are wrapping around, which does not always make sense in by itself.
I have spent (wasted) quite a bit of time already on Mastodon describing my effort of getting NFSv4 working over IPv6 with a Linux client — and if I had more time at my hands I would be trying to reproduce this with a “virtual lab”, unfortunately I don’t have any time for it! One day I will try to write up that one as well, but what the experience taught me is that the vast majority of the UI features provided by TrueNAS are actually mapped almost directly to the configuration file of the feature they are trying to set up.
In the case of Samba, I’m not sure what the exact source of the issue is – it could be similar to PostgreSQL’s documentation woes – but their documentation has always been fairly lacking for anything that is not part of the beaten path, so I’m not surprised that doing something that feels unusual is going to be complicated.
Samba Share ACLs (not Filesystem ACLs)
Okay so first of all, let’s clarify that there’s two main Access Control Lists (ACLs) that are involved in this. One is the filesystem-level ACLs which is the more “beaten path” approach: these represent which (local to TrueNAS) user can access (read, write, modify) the files. While obviously the newly-created user (which I named homeassistant despite TrueNAS’s insistance that the username is too long) needs access to the filesystem, that is only half of the problem.
What I wanted was to change the Share ACLs so that the share itself is not visible to other users. Every Samba share has ACLs, though TrueNAS comes with a generally good default:
This is already confusing because the concepts are all different from what most people expects. The important concept to explain is SID, which is a Security Identifier — just like TrueNAS I’m linking to the Microsoft documentation here, because this being Samba, Microsoft is the source for this. SIDs are a way to have a global-ish way to refer to user identities across different machines on the same network. S-1-1-0 is a special symbolic SID that refers to “everyone”, and the default basically allow anyone access to the share itself — the content within that share would then be protected by the filesystem ACL.
To make a share only show up for a single user, instead of having an entry for S-1-1-0 you need to allow only the SID of the user you want to allow access to. Both the TrueNAS UI and the documentation, at the time of writing, point you in the totally wrong direction
Help: SID. […] Either a SID or a Domain and Name is required for this ACL.
Help: Domain. Domain for the user Name. Required when a SID is not entered. Local users have the SMB server NetBIOS name:
freenas\\smbusers.Help: Name. Who this ACL entry applies to, shown as a user name. Requires adding the user Domain.
TrueNAS UI
So it sounds like you want to use freenas\\smbusers as Domain, right? Wrong! The domain is actually the hostname as configured in Network → Global Configuration. And then you can put as the Name the actual username of the user you want to authorize (in my case homeassistant.)
How did I manage to find that, while every single freaking piece of documentation still speaks of freenas\\smbusers? Well, you can actually find the right SID for one of the accounts, if you use the shell as root, and run pdbedit -Lv:
root@truenas[~]# pdbedit -Lv | tail -n 23
Unix username: homeassistant
NT username:
Account Flags: [U ]
User SID: S-1-5-21-2866400135-1316574480-2335885895-20043
Primary Group SID: S-1-5-21-2866400135-1316574480-2335885895-513
Full Name: Home Assistant
Home Directory: \\TRUENAS\homeassistant
HomeDir Drive:
Logon Script:
Profile Path: \\TRUENAS\homeassistant\profile
Domain: TRUENAS
Account desc:
Workstations:
Munged dial:
Logon time: 0
Logoff time: 9223372036854775807 seconds since the Epoch
Kickoff time: 9223372036854775807 seconds since the Epoch
Password last set: Sun, 18 Jun 2023 13:05:20 UTC
Password can change: Sun, 18 Jun 2023 13:05:20 UTC
Password must change: never
Last bad password : 0
Bad password count : 0
Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFCode language: CSS (css)If you take the SID you see in the output and put it in, instead of Domain and Name, then save, TrueNAS will actually resolve it and show you the correct Domain/Name pairing. Why and how? Well, that’s one of the positive (if we can call it so) effects of using the upstream underlying configuration files directly, rather than going through an indirection that would require translation of the configuration parameters.
So there you go, now you know how to hide shares for users for whom they are not relevant, or in general to hide them from users who can’t access them in the first place. Good luck to you!
