Auxiliary Parameters missed

[scorpoin]

Create an issue in JIRA asking for that parameter to be added.

I don't consider it as an answer. It was not a bug not a new feature we all are demanding to enable dammn old feature which was there in previous version. If some one mess-up and misconfigure even a secure box its their fault. What if a new driver met an accident its not car manufacturer fault its the driver's fault.

 

[Patrick M. Hausen]

I don't consider it as an answer. It was not a bug not a new feature we all are demanding to enable dammn old feature which was there in previous version. If some one mess-up and misconfigure even a secure box its their fault. What if a new driver met an accident its not car manufacturer fault its the driver's fault.

The two of us can discuss this all day long, that will not change a thing about the software. This is the community forum with users supporting other users. The only way to change anything - be it a bugfix, a new feature, or revert of a feature removal - is to create an issue in JIRA. That's the medium to talk to developers and product management.

 

[scorpoin]

I'm unable to open jira ticket. Any one else tried it?

 

[HoneyBadger]

@scorpoin What's the error you receive? I know there was occasionally an issue from users who had an old Redmine account and migrated, but a net-new Jira/Atlassian account should work.

 

[tannisroot]

I've opened a jira ticket about this:

[NAS-125749] - iXsystems TrueNAS Jira

ixsystems.atlassian.net

 

[scorpoin]

Please guys just comment on that opened ticket to let developers know how important this feature is for an advance user.

[NAS-125749] - iXsystems TrueNAS Jira

ixsystems.atlassian.net

 

[systemofapwne]

I just migrated from TrueNAS core to latest scale, just to find out, that I cannot use my AUX parameters anymore. This is really a shame.
Why remove a feature, some power-users depended on?

I used the aux-parameters to lock-down access and visibility depending on a users group on my active directory:

# Hide shares, that are set "unreadable" via share ACLs
access based share enum = yes

# Hide files/folders which are marked "unreadable" via Filesystem ACLs
hide unreadable = yes

#Lockdown access to only valid groups/users
winbind nested groups = Yes
winbind expand groups = 10
valid users = @admin @server @norights +DOMAIN\"nas"

Now, the only way around this is hacking deeper into the system and injecting the settings into smb4.conf our own. What a shame.

 

[tannisroot]

I just migrated from TrueNAS core to latest scale, just to find out, that I cannot use my AUX parameters anymore. This is really a shame.
Why remove a feature, some power-users depended on?

I used the aux-parameters to lock-down access and visibility depending on a users group on my active directory:



Now, the only way around this is hacking deeper into the system and injecting the settings into smb4.conf our own. What a shame.

You actually don't have to do that. You can change settings through CLI
If you want to edit params for a particular share, first (via SSH) run:
cli
to enter CLI interface
then, run
sharing smb query
to get a list of shares. Note the one you want to edit and look at its id.
Then, run
sharing smb update id
where id is the id number of your share.
You will drop into a nano-like text editor, where you remove # to uncomment the aux conf section, and input your smb config, separated by newlines if there are multiple, like so:

Then you click save and quit and it should apply.
And for global options, also while in CLI mode, you run
service smb update smb_options=""
where you put whatever options you desire inside "", separated by \n. For example:
service smb update smb_options="server min protocol = SMB3_11\nworm:grace_period = 86400"

 

[tannisroot]

I just migrated from TrueNAS core to latest scale, just to find out, that I cannot use my AUX parameters anymore. This is really a shame.
Why remove a feature, some power-users depended on?

I used the aux-parameters to lock-down access and visibility depending on a users group on my active directory:



Now, the only way around this is hacking deeper into the system and injecting the settings into smb4.conf our own. What a shame.

But I do agree that it is counter-productive to remove the feature. I am sure many in corporate and enterprise circles will also concur on this.

 

[Cellobita]

You actually don't have to do that. You can change settings through CLI
If you want to edit params for a particular share, first (via SSH) run:
cli
to enter CLI interface
then, run
sharing smb query
to get a list of shares. Note the one you want to edit and look at its id.
Then, run
sharing smb update id
where id is the id number of your share.
You will drop into a nano-like text editor, where you remove # to uncomment the aux conf section, and input your smb config, separated by newlines if there are multiple (...)

@anodos mentioned that SMB auditing is being added as a supported feature in DragonFish, but until then is it possible to add - and if so, how - the full_audit object to a share's vfs objects aux parameters?

 

[systemofapwne]

You actually don't have to do that. You can change settings through CLI
If you want to edit params for a particular share, first (via SSH) run:
cli
to enter CLI interface
then, run
sharing smb query
to get a list of shares. Note the one you want to edit and look at its id.
Then, run
sharing smb update id
where id is the id number of your share.
You will drop into a nano-like text editor, where you remove # to uncomment the aux conf section, and input your smb config, separated by newlines if there are multiple, like so:
View attachment 73728
Then you click save and quit and it should apply.
And for global options, also while in CLI mode, you run
service smb update smb_options=""
where you put whatever options you desire inside "", separated by \n. For example:
service smb update smb_options="server min protocol = SMB3_11\nworm:grace_period = 86400"

Well, using service smb update smb_options via the cli interace ended up, that I can no longer login via local accounts but only via active directory accounts. Writing my 'additional aux parameters' must have overwritten other existing settings. in /etc/smb4.conf, I do not see any changes. Time for me to reset the config to a previous backuped state to get back to a working setup.

Seriously, removing aux parameters from the WebUI is absolutely a step backwards and just causes trouble. I understand, that one wants to have an "appliance like system", but strapping it down to 'an absolute idiot safe bare minimum' on a 'power user appliance' is not the right way tbh (this is not an Apple product, lol).

 

[systemofapwne]

The funny thing is that apparently, when I upgraded from some older CORE -> latest SCALE, my aux parameters have been imported and show up and seem to be active.
However, setting them (again) via the cli tool breaks logins of local accounts. Even though the smb_options are basically the same:

 

[tannisroot]

The funny thing is that apparently, when I upgraded from some older CORE -> latest SCALE, my aux parameters have been imported and show up and seem to be active.
However, setting them (again) via the cli tool breaks logins of local accounts. Even though the smb_options are basically the same:

Yeah honestly editing via CLI even under 23.10.1 is a buggy mess, and I can't even pinpoint or understand what even some of the issues are to report on Jira. I wish I could help.

 

[dustinsterk]

Following up on this....unless I am missing something - these "Aux Parameters" are a must have for a simple task like creating an SMB share that allows users to add new files/folders but not have permission to delete them (or rename -- which is essentially a copy and delete operation).

Step 1 and 2 (from SSH command line):
chown -R root:root * /mnt/Volume/<SMB SHARE PATH>
chmod -R 1777 /mnt/Volume/<SMB SHARE PATH>

Step 3:
I needed to add two global parameters (for any new files/folders created in the share after the above commands were executed) and had originally tried to manually modify /etc/smb4.conf but noticed that file was re-written on SMB service restart. I found a thread talking about using the "Aux Parameters" field in the TrueNAS SMB Share Config web GUI to be able to add these parameters into the global config section. To my surprise this field was completely absent on those screens (TrueNAS-SCALE-23.10.1), but thankfully found this post for the solution in #48. I was able to add both parameters using the following (via command line - via cli as stated above):
service smb update smb_options="inherit owner=yes\ninherit permissions=yes"

You can then check it saved after restarting the SMB service.
service smb config

Working perfectly again, but my vote is bring the Aux Parameters back into the GUI please!

 

[Say Heading]

Just installed a vanilla version of Cobia and stumbled right into this issue.
I'm not seriously using TrueNAS yet, still investigating my use case. Quite successful though with CORE, but out of curiosity tried SCALE also.

For me the SMB aux parameter

Code:

strict sync = no

in CORE is a must, otherwise copying data from the mac is a nightmare via 1 Gbit ethernet.
So I have read about lots of complaints about the missing option, but is there an alternative GUI based method to increase network speed specifically to/from macOS?
Or is the CLI method mentioned by @tannisroot the only way to speed things up?

Edit: So it look´s like @tannisroot 's method is the only one for now. Took me a while until I sorted out how to do it exactly as I also had issues to connect via terminal app and ssh, but now file transfers are as fast as they were in CORE.

 

[Say Heading]

You actually don't have to do that. You can change settings through CLI
(...)
And for global options, also while in CLI mode, you run
service smb update smb_options=""
where you put whatever options you desire inside "", separated by \n. (...)

@tannisroot allow me a stupid question as someone who knows more or less nothing about what's going on there (and who should probably keep his hands off stuff like that - just like iXsystems would like me to...):

Do these updated smb options survive a system (or even only smb service) restart? Or do they fall back to defaults?

 

[dustinsterk]

@tannisroot allow me a stupid question as someone who knows more or less nothing about what's going on there (and who should probably keep his hands off stuff like that - just like iXsystems would like me to...):

Do these updated smb options survive a system (or even only smb service) restart? Or do they fall back to defaults?

They survive an SMB restart, so I assume it would also persist a system reboot (but have not tested this). One cavat, if you modify the parameters via cli, it does not append any config, it overwrites the entire chunk.

 

[Say Heading]

One cavat, if you modify the parameters via cli, it does not append any config, it overwrites the entire chunk.

Ouch. So resetting to defaults is another demanding task...

 

[tannisroot]

Ouch. So resetting to defaults is another demanding task...

Note that this only applies to global options. Per-share config is entirely appendable. Also, you can just query the existing config, copy it and then add more to what you already had. Also, the commands you ran before should be saved to bash history if you have the home dir configured, so you can search through them and find the one you ran before and modify it.

 

[tannisroot]

I've realized the original link to the Jira ticker got embedded in a weird way, so here it is without an embed in case someone wanted to give it thumbs up but didn't notice it:
https://ixsystems.atlassian.net/browse/NAS-125749