Auxiliary Parameters missed

[dustinsterk]

Just confirming it does persist over a reboot as well.

 

[tannisroot]

Well, got a reply on the now rejected Jira suggestion:

This is not coming back into the UI.

For valid use cases missing UI support please create a suggestion outlining the valid use case / workflow.

I suggest that everyone who has a valid use case for a particular aux parameter to create a new suggestion outlining why it should be an option in the UI.

 

[winnielinnie]

I suggest that everyone who has a valid use case for a particular aux parameter to create a new suggestion outlining why it should be an option in the UI.

Seems like an uphill battle that’s not worth the time and effort for what is likely to be struck down.

 

[dustinsterk]

I am not sure exactly why this is even a debate. Anyone using TrueNAS is probably fluent in how to configure and mange permission/shares, etc. NOT having this flexibility without using the awful cli is just silly. Just allow for us to edit /etc/smb4.conf if there is really worry about a user messing something up.

 

[winnielinnie]

The problem is, a GUI is not simply for the convenience of "adding" or "modifying" parameters, but also to quickly "review" them.

Throwing CLI commands to change parameters, which you cannot review under the Share's GUI screen, is counter-intuitive, and can cause confusion later. (There's no obvious indicator what parameters are currently being used in a Share, unless you whip up the command-line terminal.) This also makes it harder to troubleshoot issues.

I don't like this decision. I wish they had just introduced a checkbox with a warning disclaimer that allows auxiliary/custom options.



EDIT: And let's follow their train-of-thought for a moment.

If rather than simply keeping the ability to add auxiliary parameters, they instead invite "feature requests" and justifications for every... single... parameter... And let's say, ideally, they accept all of them.

Now what?

A large, messy drop-down box of many parameters? A bunch of checkboxes, text fields, and selectors all crammed into the SMB Share screen? Really? That is more ideal than what you already had provided? And for what? To prevent stubborn users from breaking their own systems, who will try to add custom options, so much so, that they're willing to go out of their way to force them via the CLI, anyways? How is this making any sense?

To borrow a comment from someone else, it feels like the "Apple" approach to things.

 

[dustinsterk]

The problem is, a GUI is not simply for the convenience of "adding" or "modifying" parameters, but also to quickly "review" them.

Throwing CLI commands to change parameters, which you cannot review under the Share's GUI screen, is counter-intuitive, and can cause confusion later. (There's no obvious indicator what parameters are currently being used in a Share, unless you whip up the command-line terminal.) This also makes it harder to troubleshoot issues.

I don't like this decision. I wish they had just introduced a checkbox with a warning disclaimer that allows auxiliary/custom options.



EDIT: And let's follow their train-of-thought for a moment.

If rather than simply keeping the ability to add auxiliary parameters, they instead invite "feature requests" and justifications for every... single... parameter... And let's say, ideally, they accept all of them.

Now what?

A large, messy drop-down box of many parameters? A bunch of checkboxes, text fields, and selectors all crammed into the SMB Share screen? Really? That is more ideal than what you already had provided? And for what? To prevent stubborn users from breaking their own systems, who will try to add custom options, so much so, that they're willing to go out of their way to force them via the CLI, anyways? How is this making any sense?

To borrow a comment from someone else, it feels like the "Apple" approach to things.

+100 to the above, and a complete maintenance nightmare for the devs who have to maintain/add/remove those "drop down commands" for every use case. What a terrible idea.

 

[Patrick M. Hausen]

Maybe follow OPNsense's model. For many of the newer subsystems (they are still in the process of a complete rework of the pfSense legacy code - for the better IMHO) they provide an e.g. /usr/local/etc/smb4/opensense.d directory where you are free to drop config snippets that will be included.

In our current case this of course implies that smb4.conf can do includes - I don't know just right now.

The promise that comes with this mechanism is:

- garbage in - garbage out, if you mess up you mess up
- your config snippets won't be touched - ever - not by reboots, nor by updates
- if updates introduce breaking changes ... see first point, your responsibility

That looks like a pretty good solution to a complicated problem to me.

 

[Jip-Hop]

Wow I just found out today that the SMB Auxiliary Parameters are gone from the GUI. Surprised I've missed this when reading the release notes...

Fortunately for me I've setup the Auxiliary Parameters I need for my shares in a previous release of SCALE... So they're still effective. But now they're hidden from the GUI.

I'm using force user and force group so all files created via SMB are owned by a certain UID. I can then use these files in containers which run a service (e.g. Nextcloud) under the same UID.

 

[Jip-Hop]

On a related note, I just noticed I can no longer create multiple users with the same UID. I now get the error:

"Uid 1234 is already used (user test has it)"

Multiple users with the same UID was useful to me because of the same reason above, files created by these users would be 'accepted' by a service inside a container expecting all its files to be of the same owner. I got the idea from @Patrick M. Hausen.

I would then limit access for each user to just their own files via SFTP with these Auxiliary Parameters:

Code:

Match Group *,!builtin_administrators
    ChrootDirectory %h
    ForceCommand internal-sftp

Fortunately the SSH service still has the Auxiliary Parameters in the GUI. But now I can't make new users with the same UID anymore... Maybe the CLI still allows for this? I haven't tried.

 

[truefriend-cz]

A simple "Unlock" button with a bold red warning can cover their butts. It can also trigger a flag when they submit a bug report that they are using unsupported / discouraged features.

It can look like this:

1. Visit your share settings
2. At the very bottom is a button to "unlock" auxiliary parameters
3. If you click it, a big, bold, red popup warns you that this is discouraged and unsupported, USE AT YOUR OWN RISK
4. You have to check "confirm" if you want to continue
5. Everyone is happy

do you can please screenshot where is it? I dont find it.

 

[winnielinnie]

I dont find it.

It doesn't exist. It's a proposed alternative to outright removing the Auxiliary Parameters feature.

 

[truefriend-cz]

It doesn't exist. It's a proposed alternative to outright removing thew Auxiliary Parameters feature.

Oh my god. I gave it a second chance. Nevermind. I'm ending with TrueNAS it for good. I will buy Enterprise servers from a competitor.

 

[rubberfoxes]

Okay, this is a silly one... but I migrated from CORE to SCALE and now this missing socket options / aux parameters field is gone. Fair enough, but hey... the settings are still there and now I can't rename the samba server at all because it's saying these options are no longer allowed. they show up when I do testparm, how can I delete them entirely without reinstalling scale?

 

[tannisroot]

You need to have access to the server's shell (either through SSH or through web ui) and change the parameters through CLI interface.
See https://www.truenas.com/community/threads/auxiliary-parameters-missed.113938/post-797889 to learn how to do this.

 

[rubberfoxes]

Okay, this is a silly one... but I migrated from CORE to SCALE and now this missing socket options / aux parameters field is gone. Fair enough, but hey... the settings are still there and now I can't rename the samba server at all because it's saying these options are no longer allowed. they show up when I do testparm, how can I delete them entirely without reinstalling scale?

Thanks. Doing the "socket options" one didn't sort it. but going nuclear with service smb update smb_options="" fixed it entirely.
THANK YOU!