Problem/Justification
(What is the problem you are trying to solve with this feature/improvement or why should it be considered?)
I understand the developers oppose to raw SMB Auxiliary Parameter editing in WebUI.
Then how about exposing some SMB Auxiliary Parameters in WebUI?
There are a few crucial SMB Auxiliary Parameters to me and many other. They are
create mask
force create mode
directory mask
force directory mode
veto files
force user
force group
valid users
follow symlinks
Of course there are a few less crucial but helpful parameters, including
store does attributes
map archive
map hidden
map system
Impact
(How is this feature going to impact all TrueNAS users? What are the benefits and advantages? Are there disadvantages?)
Nearly all competitors provides an official way to modify SMB Auxiliary Parameters. TrueNAS is the only exception I know of. Withholding such ability prohibits TrueNAS as a valid solution for many organizations and personal usage.
User Story
(Please give a short description on how you envision some user taking advantage of this feature, what are the steps a user will follow to accomplish it)
It enables SMB shares function as a dropbox that users cannot read what is submitted from other users.
It prevents junks from uploading from house keeping files of the client OS.
It simplifies sharing of some common files between users belongs to different groups.
I use force user/group and other permissions based auxillary parameters mentioned for all my shares. Would be lovely to have them in UI because editing through CLI is a PITA.
Shouldn’t be a problem to have them in GUI from my point of view, as they don’t really have a potential to damage data.
That’s not exactly true: you can still call cli, but editing auxsmbconf is now only supported for LEGACY_SHARE, which AFAIK you can no longer create.
So yeah, even more the reason to add these options.
Myself I use these options for my shares, which are almost the same as the ones in the head post:
force user=downloads
force group=downloads
valid users=@downloads
force create mode=0640
force directory mode=0750
create mask=0640
directory mask=0750
store dos attributes=no
ea support=no
map archive=no
map hidden=no
map system=no
map readonly=no
veto files=/.Trash-1000
To provide user story for why I need these: basically, I have a system where a certain dataset, for example, Downloads is owned by user downloads, and a certain app runs as that user, expecting to be able to create and edit all the files in the Downloads dataset with no issue. This also means all the files are owned by downloads user and downloads group.
That dataset is also Samba share, which can be accessed by multiple Samba users that are a part of the downloads group, and have full access to everything in that dataset. And no matter what changes they make, the permissions will stay the same and won’t interfere with the functionality of the app that does its stuff in the Downloads dataset.
You can access API docs either through the Web UI (Click your username on the top toolbar > My API Keys > API Docs) or just by going to api.truenas.com.
options.auxsumbconf does not mention that it requires purpose to be set to LEGACY_SHARE.
purpose does not mention that LEGACY_SHARE enables options.auxsumbconf.
Furthermore it tried to persuade users from using LEGACY_SHARE by saying ‘It should not be used for new SMB shares.’
And the auxsmbconf’s of existing smb shares were silently discarded when updated from earlier versions of TrueNAS SCALE. I scramble for a week to find a solution. And no one from iX came to the forums to answer how to make it work. Imagine the life of system admins when facing angry clients.
It is an obscurity in my dictionary. Especially when there is no alternative to set auxsmbconf.
It does explain that these options are only available for Legacy Shares and if you set the tab to anything other than Legacy Share, it won’t contain auxsmbconf as an option.
This is by design. The web UI does not allow setting new shares to Legacy Share and the API discourages it.
As suggested to you on another thread, the TrueNAS devs have intentionally removed auxiliary parameters from SMB shares due to the frequency with which users were breaking their own systems through misconfiguration. Given their position, you’d probably get more traction out of requesting individual parameters be added to the UI as configuration options than a blanket method to edit parameters. That said, I don’t believe that this:
should have been the case. Were the shares in question using No Preset before migrating from 25.04 to 25.10? If so, they should have been automatically migrated to Legacy Shares as outlined in the 25.10.0 release notes: 25.10 (Goldeye) Version Notes | TrueNAS Documentation Hub
All options should have migrated intact.
Yeah, I didn’t understand the tabs in there. My fault.
Regarding upgrading, I upgraded one of my TrueNAS from 24.10 to 25.10. I don’t know whether it was the culprit that the settings were not intact.
I understand the frustration of tons of support from users messing auxsmbconf and you think they are too dumb to deal with auxsmbconf. However, sweeping suxsmbconf under the rug does not make the necessities of messing aroundauxsmbconf goes away.
For those of us unfortunate souls, auxsmbconf is the make or break difference. It is non-negotiable. Taking it out leaves users no choice but jump ship to alternatives.
Likely. Our documented upgrade paths are to go from the last maintenance release of a major version to the next one to avoid situations like this. Skipping major versions is not tested and the migration logic wouldn’t have been developed with that in mind.
Right. I agree that is not the most common way forward. But 25.04 switched from Kubernets to docker and I was running docker containers in jailmaker. That’s why I waited until the dusts settled down before migration.
Would you guys consider multi-step migration of configurations? Like 24.04→24.10→25.04→25.10. It should be very similar to users upgrading every major version.
Or should users migrate gradually themselves? It can be mentioned in the release notes and shows an advice when users switch update train.
