[General] Why easy things is so complicated?

[indivision]

Ok, since no one else sees a problem with the gui on this issue I won't say any more. In OMV they went back to the user/resource table, but unfortunately the gui itself was heavily simplified and defacto destroyed. In the synology example, despite the simple gui, it is possible to click almost everything you need. in OMV there is pure debian underneath, but I'm tired of configuring everything via unix style. I miss a clear and logical menu. Now in OMV they messed up the menu, and in Scale it is illogical. And wizards won't save it, menus need to be refined. Xpenology stays?

Software made for public use has to accommodate different needs for different users. If your use-case was the only viable one for this product, it would be easy to stream-line the GUI just for you. But, that isn't really a reasonable standard to expect.

I'm not sure what simplification you are looking for in the permissions? How much more direct can permissions options get beyond Read/Write/Execute and User/Group/Other?

Are you looking for the "Set permissions to what zbw needs." button?

Yes, i search this in menu! And not find! Maybye is hided under strange submenu like static ip? In documentation is not any word about....

It's very easy to find.

Go to: Storage > [Your Dataset] > View Permissions.

Then click the edit button on the Dataset Permissions box.

Where else should it be?

 

[zbw]

Ok. Lets look. Add users. Go to dataset, view permissions. I see 3 users (root). Edit. Change user, tick "Apply user", set r/w and ok. I still see 3 users but one is changed to my user. Want add next user... i still edit first user, no Add button, no way to edit next 2 users (hided?). I see this menu before, but i not see all needed options. Next - testparm, shares are listed, permissions not. Ok, zfs permissions. Clear share - i can login from windows to share, edit, delete, etc. Now copy 3TB data as root from console to zfs mounted pool, chmod -R 777. Windows ask for password and next "access denied". Why? Samba logs is empty. This is correct behavior? How add next users? I not need zbw button but logic permission menu.

 

[indivision]

Want add next user... i still edit first user, no Add button

What do you mean by this? Are you trying to make multiple users be the owner of the dataset?

 

[zbw]

Hmmm, how else i can set multiple users to one share in samba? How i can set different permission sets to different users in needed subfolders which is setted as share?

 

[danb35]

Ok. Lets look.

Yes, let's. I've never done this on SCALE before, so I should be a good test case. Go to dataset, view permissions, and I see this:

I want to edit them, so I click on the pencil. That gives me this:

I want to add an entry for someone other than root, so I click on Add Item. Over on the right, under Access Control Entry -> Who, that changes to User, and that gives me a new field where I can select a user, which I do:

I want to add another user, so I click Add Item again and repeat for the new user. And here it is:

Click Save ACL, and I'm done. That wasn't too hard--where's the problem?

 

[indivision]

Hmmm, how else i can set multiple users to one share in samba? How i can set different permission sets to different users in needed subfolders which is setted as share?

You do this with groups. Not adding multiple users as owners.

Make a new local group. Assign that as the owning group in the permissions window we opened.

Then you can add the users you want to have access to the group. Do this in the group settings.

 

[zbw]

Ok, but this is edit acls to all dataset, what with filesystem subfolders, setted as share, and which should have other permissions?

And... maybye worth write this in documentation?

This is why i tell about direct samba share permission editor.

 

[danb35]

what with shared subfolders which should have other permissions?

If they're separate shares, create them as separate datasets and do the same thing. Otherwise I expect it would need to be done from a client computer.

And yes, it would probably be worth noting in the documentation. But--unless I'm missing something major--this is extremely simple. As I said, this was literally the first time I've touched permissions in SCALE, and that was less than five minutes (including taking screen shots and writing that post).

Now, what I just wrote up uses ACLs, which are enabled when you create the dataset as a SMB share. They're more flexible than traditional *nix permissions, but they can cause issues with other things.

 

[zbw]

Ok. Thanks for Your effort. This is not logical and not intuitive, but yes - it have chance to work. Different datasets....

 

[danb35]

There are few hard-and-fast rules about when to create separate datasets, but a dataset for each share is a good rule of thumb. As to whether it's logical or intuitive, I guess we have a difference of opinion--I was able to figure it out, without ever having touched this part of the software before, in a few minutes, so I'd consider it to be both (relatively) logical and (relatively) intuitive. Your mileage obviously varies.

 

[zbw]

I always set one filesystem and sharing subfolders. Old, working many years way even in today. Not many peoples uses a filesystem properties to set sharing permissions. Maybye time to learn modern solutions....

 

[morganL]

That's weird, it has a security level of "iX Private", and I can't change it--Morgan, any idea why that's the case?

It's also strange that Jira (now, at least) doesn't have separate "product" classifications for CORE and SCALE--since they are very different products. This means that a suggestion (which my ticket is) can't be tagged to apply to one or the other of those. Don't know if this is another artifact of the Jira cloud migration or something else, but seems like it could be improved.

A few issues here, but the suggestion is in place and visible to me and the team.

1) The Jira ticket links aren't working very well with Jira cloud.. we are looking into a fix. In the mean time provide the ticket number and the hyperlink. @wsoteros - let us know if we find a fix.

2) By default the tickets are made ix-private. We don't know whether someone uploaded any sensitive information. The triage team should review and change, but that would be next week. We'll see if that can be improved.

3) While SCALE and CORE are separate products they do share 90% the same code base. When SMB or ZFS improvements are made, they mostly go both places. If the improvement is generic to both, we'd like to enable it in both. So we don't want to split and hence have TrueNAS as the focus.

Thanks for the feedback.

 

[danb35]

Old, working many years way even in today.

Sure, that works, and for filesystems other than ZFS it's pretty much the only option. But the Free/TrueNAS UI only deals with the dataset level, not with individual directories within a dataset. It's always been that way, and it likely always will.

Not many peoples uses a filesystem properties to set sharing permissions.

I'd expect most people using Free/TrueNAS do exactly this.

 

[indivision]

And... maybye worth write this in documentation?

The questions you have are not necessarily within the scope of TrueNAS. They are more questions about how Linux works.

This is why i tell about direct samba share permission editor.

You write "share" permissions. But, you are really talking about Linux folder permissions.

That is covered in guides like this: https://linuxhandbook.com/linux-file-permissions/

You seem to be suggesting that TrueNAS should have a built-in file browser. But, that isn't really what servers are for. The server "serves" a specified folder for other computers to utilize. The server OS doesn't really care or know what the other computers do to that space.

So, it's up to you to configure which folders the TrueNAS OS needs to be aware of, manage and/or share. Then, what happens to them (including permissions) from there is up to the connecting computers.

 

[danb35]

You write "share" permissions. But, you are really talking about Linux folder permissions.

...or, more accurately, ZFS dataset permissions, since that's all you can edit in the web GUI. And really, from a user perspective, who cares how it's done under the hood? "How do I set up a share so that user foo can read and write, bar can read only, and baz can't see it at all" is a perfectly valid question for the software product that is TrueNAS, and it's legitimate to expect that the product's docs will answer it. That functionality is squarely within its core feature set, and it's a perfectly reasonable expectation that the product's docs will cover how to use its core feature set. I think it's easy enough to figure out that the omission isn't all that serious, but users really shouldn't need to look to outside docs for the basics of what the software is designed to do.

 

[indivision]

...or, more accurately, ZFS dataset permissions, since that's all you can edit in the web GUI.

Fair point. Though, you can recursively apply permission changes to entire datasets from the GUI.

And really, from a user perspective, who cares how it's done under the hood? "How do I set up a share so that user foo can read and write, bar can read only, and baz can't see it at all" is a perfectly valid question for the software product that is TrueNAS, and it's legitimate to expect that the product's docs will answer it.

I think the docs do cover that.

Here: https://www.truenas.com/docs/scale/scaletutorials/storage/pools/permissionsscale/

And here: https://www.truenas.com/docs/scale/scaleuireference/credentials/

 

[diogen]

You do this with groups.

This!
On any OS (or web app of the last few years, for that matter) r/w rights are assigned to groups.
And users are made members of those groups... Basics with some 20+ years of history...

And... maybye worth write this in documentation?

Going down this path would require specifying 2+2=4 at least once per page.
Hence, no, it's not worth it...

 

[danb35]

I think the docs do cover that.

Looks like they do--thanks for the links.

On any OS (or web app of the last few years, for that matter) r/w rights are assigned to groups.

Groups can do it, but ACLs are more flexible and granular.

 

[opensourcefan]

I am new to TrueNAS and new to running my own NAS server that isn't made for the masses, ie Synology, Qnap. I have deployed pfsense and opnsense and unifi and ran Linux for years etc so I'm not a total noob but I can definitely feel the frustration of the OP here.

Most of my transition to Scale was straight forward but some tasks felt clunky. I don't know how to explain but it's like you do one thing here then you need to go there and over there and back to there to complete it. Best word I can come up with is fragmented. Has the feel of many improvements that have added many layers.

Once you know, you know and it's simple where I suppose most of you are at. But for each thing I needed to learn I found reading many forum posts and combining much of the information to come to a solution.
For example setting up rsync and not knowing that I needed to add --password-file= etc etc into parameters and where to put the pwd file and that it needed to be chmod 600 or was never going to work.

At one point I got a handy pop up message saying I will need to assign permission or something to that effect to whatever I was doing, sorry it's all a blur. That was nice but it was the only hint that I remember.

It's possible that TrueNAS is really out of my league. If that is correct it could be a difficult transition for many. The development team is clearly brilliant, maybe too much so. Not sure what the target audience is for TrueNAS but if reaching out to non server IT pro's is a goal then I think we need to add a team looking through a different set of eyes.

Thank you all for an amazing product, I wouldn't be typing if I didn't like and appreciate it.

 

[indivision]

I once talked up the benefits of having a NAS to a friend and convinced him to get one. It was one of those simple, 2-drive Synology cases. I ordered it. Put it all together. Installed it. Configured the network. Set up shares and verified that everything was working.

Admittedly, the Synology GUI is a bit more user friendly than TrueNAS. They've "wizardified" a lot of common configurations and have put a lot of effort into making it as easy to understand as possible.

But, even with all of that, my friend basically gave up trying to use the NAS. Even the minimal steps needed to keep it running and/or install/adjust features to his needs was more effort than he was willing to invest.

The point being, at least in the context of a server, there is no GUI that can make up for a lack of effort.

The context of a server matters quite a bit here because there are so many different ways that they can be used. And that capability is considered by many to be an important feature. In other words, you COULD streamline the GUI by removing capability. For example, why even have a "Services" section if you reduce the server to only using SMB? But, then you will get a whole section of users that consider the product broken because it doesn't include all of the other features. Just the other day someone was here complaining about SCALE because it doesn't yet fully support clustering, a feature that the majority of other users likely will not be using.

The bottom line here is that a NAS is not as simple as something like a thermostat. It's more equivalent to an operating system like iOS or Windows. You have to put some time in to learn how it works. That is true, even if the GUI is absolutely perfect and you have IT experience.