Confusion on multiple datasets and users

[Tim Lawler]

Hello,
I set up a volume (I'll call it SHARE for the sake of brevity), located at /mnt/share and set the owner to
"nobody" and group owner "sharedgroup"
I gave Owner Group and Other all r/w/e privileges.

I created a user called shareduser whose home directory is /nonexistent and whose pimary group id is shareduser.

I then created the group sharedgroup and added as the only member shareduser.

shareduser has a password.

So I now have this 16TB drive called SHARE that I can mount, I gave everyone the username shareduser and the password, and everyone can log on to SHARE and find all the information there.

That worked for the past 6 months, but now people want to have their own drives or folders that no one can have access to besides them. After some reading, I feel that I need to create datasets with different permissions.

The goal is to maximize storage as well. So I'd like to create one dataset per person in the lab and put these datasets in /mnt/share/datasetname.

I did a test, where I created a dataset "mylastname" in /mnt/share/mylastname. I created a user mylastname and a group mylastname.

I gave the dataset the same permissions as SHARE at first, and set no quotas on space usage so I could use the whole 16TB if I wanted to. I looked on my computer, and I saw a folder within SHARE called mylastname, and I have full access to it (remember, I mapped the network drive using the shareduser and password credentials).

So far so good- I then changed the permissions so that only the owner has r/w/e permissions on mylastname, and set the owner to mylastname.

I then tried to open the folder, and it said permission denied. That's more good news.

Here's the issue. I cannot figure out how to access that folder. I cannot mount it as a separate drive because it is within SHARE and I already have a user/pass set up so I can get at the shared drive itself.

How do I set it up so I still have access to the shared drive but I alone can get access to mylastname?
I would then set up about 12 theirlastname datasets and users for the other people in the lab so everyone has their own folder.

Thank you!

 

[FloridaDan]

So there is some good stuff over in the Sharing forum. I wish this post (http://forums.freenas.org/index.php...fferent-permissions-to-a-common-folder.21480/) had been then when I had to figure this out, but I arrived at a very similar place as the author of that thread (though honestly, I haven't read their thread in detail.)

One of the real keys I found was "to keep it pure", meaning for example, if you're talking about CIFS shares manage everything with ACLs and in Windows.

 

[Tim Lawler]

So my problem is that I created a nested dataset? I need to make them all parallel?

 

[Tim Lawler]

Also I guess I cannot have everyone use a single sign on for the share drive and a separate one for the private?
I basically need to give everyone access via a user and password that has permissions set up to have full access to share and only their personal drive?

I think that makes sense. Does it make sense to you?

 

[Tim Lawler]

No I'm still confused.

What I just tried:
I created my dataset "lastname" within SHARE
I set the permissions on it to r/w/e for me only.
I tried to open the folder, having logged in with shareduser. I could get to SHARE and everywhere on it fine, couldn't access "mylastname."

Again, so far so good. I then had the user set as mylast name with the home directory of /mnt/share and the primary group of sharedgroup.

I looked at sharedgroup and the only two members are mylastname and shareduser.

I tried to map the drive as mylastname instead of shareduser, and it says access denied.

Shouldn't I be able to get in as either user now??? What am I doing wrong?

 

[Tim Lawler]

Essentially where I am right now is that I cannot configure the permissions of /mnt/share and /mnt/share/mylastname differently, which is making this difficult.

Any ideas???

 

[FloridaDan]

OK, so no, I don't think that the fact that you created a set of nested folders/shares to be a problem per se; I think that the nested thing could be possibly be made to work, but I think there's always going to a bit of a compromise at the "highest" shared level. Setting these up in parallel would be the easiest, but it would mean that everyone would have their own "private" folder as well as a separate "common" area. So essentially two mapped drives as opposed to potentially one. I honestly got it to work both ways.

For clarity (and apologies that I don't have a drawing program handy):

The Nested Way:
--------------------------------------------------------------------------------
| Mapp_Share |
| |
| ----- ----- ----- ----- |
| user1 user2 user3 commn |
| |
------------------------------------------------------------------------------------------------------------------------

In this way everyone would "map" to "Mapp_Share" but only have permission to their folder and the common place ("commn"). When I did this with CIFS shares, I did it like this:

• The owner of the Mapp_Share data set was the Windows Admin user (who has to be created in FreeNAS.) The group was a special group that contained everyone (user1, user2, user3, and all the admins).
• For each of the individual "private" areas (user1, user2, user3), the owner was the user whose folder it is (for "user1" the owner was "user1".) The group was an admins group that contains my Windows admins.
• The type of ACL was Windows for everything (I could make it work with some Unix types in there, but I didn't document it that way.)
• All permissions were then managed in Windows, meaning I went in and removed the permissions for "everyone" for all the folders (basically you're not seeing anything, anywhere unless you're user1, user2, user3 or an admin.)
• Everyone has to at least be able to traverse Mapp_Share to get to their folder or the common location. However, I kept finding that to be fragile, meaning it always seemed that it remained possible to create files and folders in Mapp_share. I didn't care for that so I went the other route. I do see this fragility or my lack of understanding as a "down side" to this approach. That said, I think that this could be solved, I just haven't gotten there yet. (I have it on a personal to-do list, just because it is bugging me.)

The parallel way:

--------------------------------------------------------------------------------
| |
| ------- ------- ------- ------- |
| |user1| |user2| |user3| |commn| |
| |share| |share| |share| |share| |
| ------- ------- ------- ------- |
| |
--------------------------------------------------------------------------------

This is basically the same as the Nested way, but just lacking the Mapp_Share:

• The owner is the user (user1, user2, user3)
• The group is an admins group
• The ACL types are all Windows.
• All permissions are then managed in Windows.
• For this one, everyone has to map to two places. Their "place" and the common location. While a little kludgy it doesn't permit some of the clutter that I could see coming about from just sharing High_share above.

I think that this is a pick which one fits your situation best.

In figuring this out, I did take the step of making several users and then trying out the ideas so I could see what it would really look like. That was a bit tedious, but nothing that couldn't be tracked with a drawing and a chart on a notepad. The tests were simple:

• Can I get there?
• If I can, what can I see?
• If I can see, what can I do? (Create, delete, execute, modify)

In doing this I found that alot of the older posts in the Sharing forum have some really good ideas in them, but the software itself has evolved to the place where some of the specific steps are no longer necessary. I also found that I had much more success when I followed the advice in one of the posts by either an admin or a developer (and I'm sorry I don't even recall whose post it was) that said not to mix ACL types. I was also very cautious about I used the "apply recursively" function when changing permissions on a dataset.

If you do something along the lines of the Nested Way, Mapp_Share cannot be the highest dataset in the volume. The highest dataset in the volume appears to need to be a Unix ACL type, at least if you're having your logs stored. When I made the highest level a Windows ACL, I don't recall FreeNAS complaining, or even barfing, but I didn't get my logs saved anywhere. So when I tried the Nested Way, I did this:

/mnt/storage/ Was my highest level dataset. It's ACL type remained Unix. This is where /.system and the other log directories got created.

Then under that I made /mnt/storage/Mapp_Share with my other stuff in Mapp_Share.

I've since done other things in /mnt/storage to fit my other needs.

 

[Tim Lawler]

What's the difference between Unix and Windows ACL? Currently mine is set to Unix everywhere. I do connect to this drive via both windows machines and fedora/linux machines, so how would this effect my linux box?

The parallel way you described...how do you get that to work with just one zpool? I don't want to manually split the data into individual drives.

 

[Tim Lawler]

I guess I cannot move beyond my confusion until I understand the following.

I have a zpool /mnt/share and a dataset /mnt/share/mylastname

share is set to nobody and sharedgroup for the owners, and all 9 permissions are checked, so everyone can do everything on it.

the dataset is set to the group and user owner = mylastname, and only the owner has any r/w/e permissions.

I cannot access mylastname if I map the drive as shareduser. Again, this is perfect.

But I cannot map the drive AT ALL if I try to map it as mylastname. mylastname's primary group is mylastname but it is a member of sharedgroup.


Why can I not access SHARE as mylastname? If I can't figure this out, I can't figure any of it out. Any ideas as to what I am doing wrong here?

 

[FloridaDan]

OK, so, I guess let's go in order:

• The difference between Windows and Unix ACLs is beyond the current scope. I'd suggest Googling. You're going to have to come to your own peace about the differences, my experience says that everyone thinks about or understands that difference a little differently. The best way I know to sum it up is that "they don't line up exactly, Windows rather went overboard, and what is possible in one is 'generally' possible in the other probably not exactly the same way."
  
• In either scheme I can connect to any of the shares from Windows, Ubuntu, and Mint. Depending on "who" I am, and which share I'm trying to touch, I may get prompted for a password on Unix machines. This is generally once per session (as I don't tell the OS to persist my credentials for more than that.)
  
• In the parallel scheme, each "folder" is both a separate dataset and a separate share. So I have these datasets:
  • /mnt/storage/user1
  • /mnt/storage/user2
  • /mnt/storage/user3
  • /mnt/storage/cmmn
    
    I then have a share for each of those datasets. No one but me knows that /mnt/storage exists, it is NOT shared. The permissions are setup as described above.
• I do no have any direct insights into what you're "doing wrong", but I suspect that it is bound up in the answers to one or more of the following:
  • "Who you are" when you attempt to map this drive, i.e. what user you're loggin to the "remote" machine as.
  • What machine (Windows or Fedora) you're using.
  • What users and groups you have on the "remote" machine and on the FreeNAS box.
  • The kind of shares you're using. The general consensus I got from around here was that CIFS shares were the way to go.

The way I worked this out was first testing in my Virtual Box sandbox and then refining the ideas on my newly minted FreeNAS physical box. I took the attitude that datasets are basically "free" (so create a few and they them out, you can delete any that don't work out) and that as my pool was also basically empty, so I couldn't do too much harm (if I did installing FreeNAS is really easy.) I'm guessing that your pool is also empty, or close to it, so make sure you've got a good back-up and try some things out.

I don't have all the notes that I took handy at the moment, but if I remember right, when the ACL type on the datasets is UNIX, the group was "more important" than the owner. That said, if I also remember correctly, I had a hard time getting Windows to interact with the share as anyone but "everyone" (this may be the answer to one of your questions above, depending on the particulars you didn't share.) That particular behavior in Windows rather defeats the purpose of having "private" folders; it also started me on the path to understanding that I needed the ACL type to be "Windows". I also borrowed heavily from this video:

View: http://www.youtube.com/watch?v=PhYkZlbBbwk

Some of what the presenter does is not necessary and/or does not work in the version of FreeNAS that I'm working with (9.2.1.5). I just kept working with it I arrived at the solution I presented above.

I would also add that this all became much easier once I stopped struggling with my preconceived notions of what "should" work and just went with what I could experimentally confirm did work.