I have a read-only share for a few people, that includes a lot of files they shouldn’t see. Not for security reasons, but for clarity. About 90% of the files are completely unnecessary for the users, making it difficult for them to find what they are actually looking for. These files have to be there for other reasons. Luckily they are easily identifiable by their name.
I previously used the smb veto parameter to simply hide files from the share, but since Cobia this option has completely disappeared and the share silently started to show all of these files.
I’d also like to add that I’ve tried to follow the instructions in this post:
But I’m having difficulties having my changes stick. I can see my old auxsmbconf Veto-command there, but it’s commented out.
Simply uncommenting and saving doesn’t do anything, it stays commented. Changing the command itself doesn’t do anything. But if I add another aux parameter line, or if I remove one, the changes do actually stick! Except everything gets automatically commented out again.
I feel unnecessarily forced to go on a dangerous path with potentially breaking cmd/cli commands, and on top of that I’m being bullied to frustration, further increasing the risks. This used to be so easy with just a text box under advanced settings.
I completely disagree on this being a heavy handed approach. On the contrary, I think just vetoing certain files is a really simple solution to the problem. Going through the pain of creating shortcuts to thousands of files, and having some sort of script that in real-time updates those shortcuts, creating new ones and deleting old ones. That would in my opinion be the unreasonably heavy handed approach to a very simple problem.
But since I seemingly can’t do the simple solution, I’m all ears on what that shortcut solution would look like. Say I have a shared folder with shortcuts to the real files I want to share. Would the real files have to exist somewhere within the share, or can they be outside of it?
Also, how do I keep those shortcuts updated on what’s going on with the real files? In my case the filtering is just based on filename, so only files which match a simple pattern need to be shared.
graph TD;
A((tank)) --> B((business_office<br>*Dataset*));
B --> C((management<br>*Dataset*));
or this:
graph TD;
A((tank)) --> B((business_office<br>*Dataset*));
A --> C((management<br>*Dataset*));
LONG FORM CONTENT BELOW
This diagram represents a fairly well-used and respected data structure, I consider it best practice. It’s simple but infinitely scalable in complexity.
graph TD;
A((tank)) --> B((department_shares<br>*Dataset*));
B --> C((business_office<br>*Dataset*));
C --> D((management<br>*Folder*));
C --> E((office<br>*Folder*));
C --> F((public<br>*Folder*));
B --> G((engineering<br>*Dataset*));
G --> H((management<br>*Folder*));
G --> I((office<br>*Folder*));
G --> J((public<br>*Folder*));
You would then create Microsoft Security Groups in Active Directory, or just UNIX users/groups locally on the TrueNAS, Then you can go about doing ACLs
The schema can be whatever you want as long as it’s consistent, something like orgname_business_office_all Security Group would have Read and Traversal access to the root business_office share.
We’d also want Read and Traversal access for everyone in the org, Domain Users would probably work in most situations.
This root business office dataset/folder can theoretically have data in it, but it shouldn’t.
You can use Group Policy to push down and map the drive and put a shortcut at whatever depth in the share you want, right on the users desktop.
Then we’d have the orgname_business_office_all have Write access in addition to Read and Traversal for the office folder.
The public folder could have Read access for everyone in the org, Domain Users would probably work in most situations. This also may not be needed in many situations.
Finally we’d need one more Security Group called orgname_business_office_management and they should be the ONLY ones who have ACL ReadWrite or Traversal for the management share under each department.
Shortcuts to other shares is really dangerous, and it also depends on how you do it. You can’t, as an example use Samba’s wide_link aux param on TrueNAS. You can, however, make a shortcut in Windows. Lets say your Z Drive is //truenas/public and your S Drive is //truenas/engineering, there’s nothing to stop you from making a Shortcut in Explorer that goes to the other share. But it’s bad practice.
The shortcuts should be on the users desktop, put there by GPO.
I’ll have to re-read this a few times to fully understand everything, but it seems like you assume everything is neatly organized into folders.
The situation is that everything is dumped into a single folder. The software that hosts the image/video library scans each file to be shared and creates about 10 new files next to it, in that same folder. The location of these can’t be changed, which is frustrating, but it is what it is. Most people can access this library as intended by the software by installing the client software, but for those internally that can’t install that, I’m also sharing the folder where they can access the images/videos via SMB. They’ll now just have to wade through 90% unnecessary crap to find the files they’re actually interested in.
The veto option worked beautifully, just ignore these filename patterns, and like magic, only the interesting files remained.
Im sorry for pushing back so hard, but im trying to explain my rationale. In native SMB protocol, on Windows file sharing, there isn’t a direct equivalent to the “veto files” feature found in Samba.
Much like all of the weird problems Apple devices have had on SMB over the years, going out of spec to add features is possible, but it sometimes has unintended consequences. A whole module had to be created… vfs_streams_xattr (samba.org)
That websocket looks like a similar approach to what I mentioned in my second post. I hope it’s not exactly the same (the guide I linked uses the cli), because it didn’t work (it automatically comments out all aux parameters I try to set). Will have to look into it and learn how that works.
Figured out how to websocket to the server. It seems that I already have the proper Veto files auxsmbconf there, it’s just not working. I also figured out how to edit it via the websocket, but still no luck in getting it to actually work.
Like I said earlier, in the cli, the auxsmbconf line is commented out and I can’t uncomment it. Maybe this has something to do with it?
