Auxiliary Parameters missed

[truefriend-cz]

Hi. After upgrade to Cobia i missed setting for SMB "Auxiliary Parameters". How i can revert to enable?
SMB Service:

Adding new SMB share:

 

[truefriend-cz]

SMB Auxiliary Parameters missing from Cobia.

With the release of Cobia (v23.10.0), the auxiliary parameters input option have been removed from both the SMB service and SMB shares themselves....

beta.reddit.com

Really totally removed this function?

If so, please advise how I can get the files to be stored (SMB protocol) on the NAS with file rights set under the "root" user and not as the currently logged in user?

My solution in Bluefin is adding to auxiliary parameter "force user = root" as an in the share settings. But after upgrade to Cobia my settings is missed. As well as the my other many parameters.
It would be nice to point out more in the documentation what functions you will lose by upgrading rather than what you will gain.

By the way why was such a good feature removed?

 

[Daisuke]

force user = root

Just curious why would you use root user, that’s prohibited in SMB. Best is to use an assigned low perms user, which can be used in external servers to access the SMB. External user logging as root could destroy everything, definitely not the correct approach.

Removing the aux parameters is a good decision IMO.

 

[truefriend-cz]

Just curious why would you use root user, that’s prohibited in SMB. Best is to use an assigned low perms user, which can be used in external servers to access the SMB. External user logging as root could destroy everything, definitely not the correct approach.

Removing the aux parameters is a good decision IMO.

Because another user with access to the same shared folder cannot handle the files and folders created by another user in any way even though they are allowed for full access in the ACL. Files and folders in a given share may only be used by the person who created them.
Thus, each user who has permission in the ACL filesystem has access only to their own files in the given share, but not to folders and files created by another user.

I figured it out by wanting to back up data from my admin account to another NAS by manually copying the folders in the form of "crtl+c, ctrl+v" and found that the size of the copied content did not fit me. Gradually I came to the fact that there is a problem with the permission. When I assign root access permissions via the "force user = root" command, all users have equal access to files and everyone gets access to folders and files created by another user in the same share.

I got around it until now by forcing storage under root rights where root was allowed in the ACL filesystem for full access and access to individual shares and if I wanted to do some access individually (some user only read but not delete) then I resolved via SMB ACL.
Or I solved it through the ACL filesystem when I set the authorization to be overwritten even for subordinate objects, but then other users could not read, run, write, etc. It is because each user is allowed something different and this applies (in ACL filesystem) for each user separately but not for all objects in the given share (only SMB ACL solves this, but also incorrectly, because ACL filesystem has a higher priority than SMB ACL ..... SMB ACL has a higher priority only if the system user (root) has access to the file system and all folders and files have this owner).

---

Different ownership of created folders and files (without force user = root parameter) I used Filesystem ACL when, for example, I wanted to create users' home folders in one share.
For example:
\\NAS\\Homes\Peter
\\NAS\\Homes\Julia
\\NAS\\Homes\John

where each user created a "Peter, Julia, John" folder from their own account and never got into another user's folder even though they saw it in \\NAS\\Homes\

I've used all Bluefin TrueNAS servers and previous versions this way and can't complain about it. Simple, functional.

 

[Daisuke]

Files and folders in a given share may only be used by the person who created them.

The root restrictions were introduced a while ago in Samba. I believe iX simply decided to properly enforce them at UI level, by blocking any possible manipulation that could harm the system.

When I assign root access permissions via the "force user = root" command, all users have equal access to files and everyone gets access to folders and files created by another user in the same share

I understand now your requirements. You basically want a group of users to access and modify a specific dataset. I still think you can do this by setting the dataset permissions to be less restrictive for group, instead of 755, you set it to 775 and assign all users to a common group assigned to dataset. Each user belonging to that group will be able to read, write and execute anything in that specific dataset. Yes, you will end up with multiple owners for different files, but they will all have access and be capable to manipulate all files and directories. In previous scenario, everything was owned by root.

 

[truefriend-cz]

The root restrictions were introduced a while ago in Samba. I believe iX simply decided to properly enforce them at UI level, by blocking any possible manipulation that could harm the system.

I understand now your requirements. You basically want a group of users to access and modify a specific dataset. I still think you can do this by setting the dataset permissions to be less restrictive for group, instead of 755, you set it to 775 and assign all users to a common group assigned to dataset. Each user belonging to that group will be able to read, write and execute anything in that specific dataset. Yes, you will end up with multiple owners for different files, but they will all have access and be capable to manipulate all files and directories. In previous scenario, everything was owned by root.

Yes, you got that right.
I don't want to solve it through groups, because then there are other problems when combining the dataset with other services such as VM, Jail for applications, etc., when they cannot read or write to the storage correctly and it is not possible to find out why this is so.
For VMs, you can add libvirt users (I don't have it in front of me, I'm writing it from memory), but with application jails, it's a different case every time (some jails overwrite the file permission mask, etc.) and a paradox occurs when through a plethora of combinations of different groups, users and authorization is security at a worse level (you can't monitor everything separately) and it's better to allow one user (the highest for the OS) globally and then just control access (allow, disable) with logging. It's easier to manage and easier to secure. When an attack occurs, I know from where and where it was applied, and this also answers the question of which service or machine was attacked.
Simply, it does not cause a deadlock when there is no solution.

On the current build of Cobia, how can I set up sharing so that, across logged in users, folders and files can be accessed by other users than just the ones who created them?

 

[tannisroot]

Just curious why would you use root user, that’s prohibited in SMB. Best is to use an assigned low perms user, which can be used in external servers to access the SMB. External user logging as root could destroy everything, definitely not the correct approach.

Removing the aux parameters is a good decision IMO.

I completely disagree. Auxiliary parameters are useful far beyond just setting "force user".
For example, you could set minimum smb version with `server min protocol = SMB3_11` or `server multi channel support = yes`, or other various obscure features that have no place in UI but still have their use.
If IX has a problem with "force user" specifically, they should have just added a sanitize check prohibiting setting it to `root` in aux parameters, removing a general option that allows that is a bit sloppy.
More than that, now users who had stuff written in auxiliary parameters can't access or change it through UI and have to tinker through CLI, which does not allow for more than 1 line of aux parameters.

 

[truefriend-cz]

I completely disagree. Auxiliary parameters are useful far beyond just setting "force user".
For example, you could set minimum smb version with `server min protocol = SMB3_11` or `server multi channel support = yes`, or other various obscure features that have no place in UI but still have their use.
If IX has a problem with "force user" specifically, they should have just added a sanitize check prohibiting setting it to `root` in aux parameters, removing a general option that allows that is a bit sloppy.
More than that, now users who had stuff written in auxiliary parameters can't access or change it through UI and have to tinker through CLI, which does not allow for more than 1 line of aux parameters.

I absolutely agree. For me, it makes no sense to remove the Auxiliary parameters function. I would like to know the reason why this function was removed and if there is a plan to return this function again.
-
I don't understand this step, because when I look at reviews of successful products (unraid, etc.) on the internet (YouTube, etc.), including paid ones, this is one of the main features why people prefer TrueNAS over other products. Just watch a few videos about TrueNAS and pretty much every YouTuber mentions it as a very handy feature.
1. is that there is a feature to be able to share a nested folder as another share (subfolders sharing)
2. Auxiliary parameters function
Furthermore, the product does not offer something that the other products should not have

 

[winnielinnie]

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

 

[katbyte]

I too would like to know why this was just removed without a functional alternative?

I need this to configure case sensitivity and the default file mask - this literally breaks truenas smb shares for me and manually editing the smb4 file that is reset anytime the ui restarts the service is not a solution

 

[katbyte]

(it doesn't look like i can edit posts?)

Seems like there was opened as a bug in August: https://ixsystems.atlassian.net/jira/software/c/projects/NAS/issues/NAS-123594 - and from discussion/linked issues it has been purposely removed to "remove sharp edges" which is a shame.

If anyone knows how i can achieve the following options in a persistent way i would be eternally thankful:

case sensitive=yes
preserve case=yes
short preserve case=yes

 

[Redcoat]

(it doesn't look like i can edit posts?)

Not yet - there's a minimum number of posts, or an evalation period, to be passed before edit capability is available (I don't know the criteria...).

 

[winnielinnie]

If anyone knows how i can achieve the following options in a persistent way i would be eternally thankful:

For the meantime, I think you can if you use the "in-house" TrueNAS CLI tool. And it will remain persistent across reboots. (Yes, the name is confusing. The tool is actually called "CLI", even though this is also an abbreviation for the unrelated general terminology "command-line interface".)

 

[winnielinnie]

Allow me to add another reason for Auxiliary Parameters: a custom WORM (write once, read many) setting

iXsystems is not unaware of WORM. In fact, they added WORM as a preset for SMB shares! The problem is, you cannot change it from the default 5 minutes. With Auxiliary Parameters, you can use any amount you want: 30 seconds? 1 minute? 10 minutes? You get to control it.

 

[tannisroot]

For the meantime, I think you can if you use the "in-house" TrueNAS CLI tool. And it will remain persistent across reboots. (Yes, the name is confusing. The tool is actually called "CLI", even though this is also an abbreviation for the unrelated general terminology "command-line interface".)

You actually cannot because CLI does not allow for adding multi-line configuration.
If you want to add multi-line config there is literally no way to do so anymore, which is why everyone is so pissed off about the removal.

 

[bcat]

You actually cannot because CLI does not allow for adding multi-line configuration.
If you want to add multi-line config there is literally no way to do so anymore, which is why everyone is so pissed off about the removal.

That seems unlikely... what exact midclt command are you trying, and what errors are you getting? It's just JSON, so presumably you can embed newlines in the usual way.

 

[tannisroot]

That seems unlikely... what exact midclt command are you trying, and what errors are you getting? It's just JSON, so presumably you can embed newlines in the usual way.

This was discussed on Discord with an iX employee before so I will just link to a jira ticket for this:

[NAS-124847] - iXsystems TrueNAS Jira

ixsystems.atlassian.net

 

[fchk]

I'm screwed by the missing Auxiliary Parameters as well.
I've got a share with these parameters:

>>>>
force create mode = 0664
force directory mode = 0775
create mask = 0664
directory mask = 0775
force user = austausch
force group = austausch
veto files = /.*/
store dos attributes = no
map archive = no
map hidden = no
map system = no
<<<<

This share is used for data exchange with a 3rd party software (some kind of hot folder). I need to strip all attributes in order to prevent this 3rd party software from hanging. These settings are working just fine in Angelfish and Bluefin, but without any replacement feature I can't just upgrade to Cobia.

There might be 1000 other useful cases whre the satndard ui isn't enough. Why was this removed then?

 

[anodos]

I'm screwed by the missing Auxiliary Parameters as well.
I've got a share with these parameters:

>>>>
force create mode = 0664
force directory mode = 0775
create mask = 0664
directory mask = 0775
force user = austausch
force group = austausch
veto files = /.*/
store dos attributes = no
map archive = no
map hidden = no
map system = no
<<<<

This share is used for data exchange with a 3rd party software (some kind of hot folder). I need to strip all attributes in order to prevent this 3rd party software from hanging. These settings are working just fine in Angelfish and Bluefin, but without any replacement feature I can't just upgrade to Cobia.

There might be 1000 other useful cases whre the satndard ui isn't enough. Why was this removed then?

CLI parsing of newline character (and some other edge cases) are scheduled to be fixed in 23.10.1 NAS-124847, you can run the following commands:

Code:

midclt call sharing.smb.query | jq

Then take the id for your share and run command:

Code:

midclt call sharing.smb.update <id> '{"auxsmbconf": "<string containing new line characters>"}'

if for some reason you are on Cobia and this breaks you.

CLI / API access to this field will not be removed. This was removed from webui due to large number of bug tickets being filed in which users had filed after inserting ill-advised auxiliary parameters, and also customer outages caused by the same.

There are some users who are familiar with samba and have very specific setups / situations that need fine-tuning, but many users are just following some online how-to guide (that may contain significantly bad advice).

I won't go into full details, but for a trivial example there were some prominent reddit instructions that advised setting the vfs_crossrename size limit to a JSON object via auxiliary parameters. strtoull converted this to a size limit of zero resulting in all cross-dataset renames for the user to be rejected in a particular way that when combined wth vfs_recycle resulted in all recycle operations automatically purging the files from child datasets (rather than moving them to the recycle bin). It's all well-and-good until users start losing files unexpectedly and filing tickets.

That said, you can file suggestions (via jira tickets) if there are fields that should be added to the webui and properly supported. If you do file tickets though, please first check whether the parameters you want set are actually current samba defaults (more often than not, people are just setting parameters that are already defaults).

 

[Patrick M. Hausen]

Force user and force group come to mind. These are great if you are managing a datastore/dropthing of some sorts where evryone who can authenticate should have exactly the same view.

Believe or not I have seen this as the dominant model in corporate environments, too. Everyone who can mount "drive Q:" has full access, period. Everyone who should not, gets no access at all.

Windows ACLs are way too complicated for users, IMHO.