SOLVED Volume Default Permissions

[SCS]

I just deployed a new FreeNAS box and I was going through and trying to follow a guide from a user on here for sharing and permissions. In the past I'd just left it as full unrestricted access but I am interested in locking it down now that I am storing work related content on the server.

After not having much luck I set everything back to the way it was prior for my "Cleanup_Tools" data set. Which was the only one I'd been attempting to apply the guide on as it would have been the most easy to redeploy as it's full of free tools.(included below)

I had a hard drive high temp warning from a few days ago during a scrub I wanted to clear so I can see if it happens again after swapping out some fans.

When I booted back up I could no longer access any of my shares, nor could I access the FreeNAS server via \\Freenas to view all the available shares. This make me think it's a volume permission issue that I may have accidentally altered, that only took effect after I rebooted because I confirmed that I had access to my "Cleanup_Tools" dataset and share after reverting the changed I'd made and before rebooting.

I created a snapshot and ZFS Send | Receive it to a new dataset "CleanupTools" to see if what ever the permission is would be inherited as I hadn't ever had to enter credentials for accessing any of the content if you were on the correct LAN. It too is inaccessible.

I can't seem to see where anyone has the default volume permissions upon creation.

 

[JohnDigital]

It seems to me that root can always access the files no matter who the owner is right? So there is no reason for root to own any of your (non jail/system) datasets, unless it absolutely positively needs to be locked down. "Edit: I overlooked that "massive store" is the name of your mounted volume.. Its ok for root to own that." I always create a user that is my account that owns all the (media, pictures, softwares, documents) datasets. Then, I create a user named guest, with a group of guest, then I make guest its own dataset, and give it full blown ownership and 777 access to the dataset, then when I share it I go into the advanced area and select only allow guest access. For all other datasets my user and password are needed. If there are multiple users you can do group access rights. I hope this makes sense.

I have never used nobody:nogroup to accomplish this. If you want anyone to be able to access whatever dataset you can apply the same guest permissions to that dataset, only I wouldnt do it this way for anything you arent ok with losing if somebody accidentally deletes it or something. So on those you might want to mount as read only when you share it.

 

[SCS]

It seems to me that root can always access the files no matter who the owner is right? So there is no reason for root to own any of your (non jail/system) datasets, unless it absolutely positively needs to be locked down. "Edit: I overlooked that "massive share" is the name of your mounted volume.." I always create a user that is my account that owns all the (media, pictures, softwares, documents) datasets. Then, I create a user named guest, with a group of guest, then I make guest its own dataset, and give it full blown ownership and 777 access to the dataset, then when I share it I go into the advanced area and select only allow guest access. For all other datasets my user and password are needed. If there are multiple users you can do group access rights. I hope this makes sense.

I have never used nobody:nogroup to accomplish this. If you want anyone to be able to access whatever dataset you can apply the same guest permissions to that dataset, only I wouldnt do it this way for anything you arent ok with losing if somebody accidentally deletes it or something.

I think part of my issue is I like the use of UNIX permissions and I'm not thrilled about using Windows Permissions as it seems is that is what every article states to use for cifs which is what I'm currently sharing via.

I have a primary user of firstname.lastname from accessing the shares that I wanted to authentication on. While doing so I found that even after giving myself owner and group access on the share it would not let me map the network share using my credentials, but I could see the share and have read only access of it via \\freenas\*share*.

This is what caused me to just roll back to what had been tried and true for me in the past before I rebooted.

The nobody:nogroup was suggested years ago when I build my last system and i had no concerns of securing it. As far as recovering from a deletion I have snapshot every 2 hours retained for 2 months to account for any sort of mistakes. Once I get my data in place my changes are minimal so the constant snapshots actually creates minimal additional space in my experience nor has it show to impact performance during scrubs.

I'm curious if I could reinstall FreeNAS to new boot media and import my ZFS volumes and try to set my setting and permissions again. Do you know if this would allow me to start over, or would my current permission situation continue as well?

I'll attempt your suggestion tomorrow and report back, although I'm wondering if the volumes permissions need to be set to something particular to operate properly?

Thank You,

Steven

 

[JohnDigital]

I use only UNIX based systems (99.1%). Because of the sparse Windows systems that do connect my shares are all samba/cifs as well, it has not been an issue because of the wide support on every system for cifs/samba. I am (almost) no help when it comes to Windows Permissions ACL. When I access my NAS on my work laptop (Windows 7 Pro) it has no issues using my creds for accessing. I set a system up for a friend this last weekend and this is also how I did his, and it worked first time. But it was from scratch... He is mainly a windows user and I am using ALL UNIX perms.

Are your systems dataset and jails and such on a different pool(s) or are everything all in one pool? If you have separate pools, recursively own your main TANK to your user:group with all owner/group boxes checked and read/execute for other. If all in the same pool do everything BUT the root of the TANK and the jails root your user:group recursively (basically all media and such, everything you are sharing or want to share). Then either check or delete/recreate all your samba shares, and DO NOT apply default permissions. This "should" work. You can allow guest access (other) or not in here as well. Then FreeNAS handles all the permissions. When you mount or access from windows use your freenas' users creds. This absolutely works as I just did it last weekend and I have had mine set for so long now..

I would suspect that exporting/importing the pool the file permissions would be there until you destroy the pool/dataset, but I could be wrong, frankly I really dont know--good question. In this case of destroying you also destroy the data, so that is a hard no--unless you have backups and want to go that route. We can certainly figure this thing out if you start from scratch, but I think that isnt necessary.

Edit: Test the above on your Cleanup tools dataset then share it as I have said. This should work.

 

[SCS]

Are your systems dataset and jails and such on a different pool(s) or are everything all in one pool?

One Pool.

If you have separate pools, recursively own your main TANK to your user:group with all owner/group boxes checked and read/execute for other.

I don't, I only have one pool at this time. Hadn't really anticipated the power consumption of 10+ 7200RPM drives to be as high as it is, as I previously was using 5900RPM and hadn't expected there to be such a significant difference. I think most future expansion would be in SSD pools as things go on sale, but I digress.
Started with Share dataset "CleanupTools" assigning the following permissions.

If all in the same pool do everything BUT the root of the TANK and the jails root your user:group recursively (basically all media and such, everything you are sharing or want to share).

Root of my TANK, or Massive_Store in my case as well as Jails as all set to root:wheel as seen in the image of my initial post.

Then either check or delete/recreate all your samba shares, and DO NOT apply default permissions. This "should" work. You can allow guest access (other) or not in here as well. Then FreeNAS handles all the permissions. When you mount or access from windows use your freenas' users creds. This absolutely works as I just did it last weekend and I have had mine set for so long now..

I deleted all of my shares.

Recreated a share:

Edit: Test the above on your Cleanup tools dataset then share it as I have said. This should work.

After following such and mapping the Drive via my Windows 8.1 box using my creds:

Oddly after creating the share I ahve to disable SMB and then reenable it before newly configured share will show up listed as available to map or via \\FreeNAS\

I would suspect that exporting/importing the pool the file permissions would be there until you destroy the pool/dataset, but I could be wrong, frankly I really dont know--good question. In this case of destroying you also destroy the data, so that is a hard no--unless you have backups and want to go that route. We can certainly figure this thing out if you start from scratch, but I think that isnt necessary.

This was me just trying to wrap my head around a nearly worst case scenario as I wasn't looking forward to having to load the box up with 1TB & 2TB drives to backup the data before nuking to rebuild as a worst case.

------------------------------------------------------------

Lastly food for thought, I had originally been planning on assigning all of the datasets with me as the owner (also as you suggested) but to have a specific group for each dataset, and just add future users to that dataset respected group so that I could have more granularity control permissions via a group level assigned per dataset (my owner permissions, dataset specific level group permissions, and then other/guest permissions.)and I would just add specific users to those groups as needed. This made more sense to me instead of using my user accounts group and restricting another users via the "Other" permission. I'm not sure if I'm explaining this well, if not let me know and I can try to clarify better. If that did make sense, what is your though on that sort of permission, as I was considering making another post on it as it is a entirely different subject over just regaining access to my data.

 

[JohnDigital]

I would stick with one or three groups and multiple users, easy to administrate that way, then if needed you can invite users to multiple groups. Im glad this is working for you without having to rebuild or restore or any of that jazz. You now have the blueprint, now you can replicate this knowledge onto other shares/datasets. This way you can give other users access with their own creds and allow or disallow them to specific shares via the groups. Certainly you are on the right track.

Restarting smbd is always a good idea after meddling with your shares. I forgot to include this in the instructions, apologies. Glad everything is starting to work out for you. Good luck!

 

[SCS]

I would stick with one or three groups and multiple users, easy to administrate that way, then if needed you can invite users to multiple groups. Im glad this is working for you without having to rebuild or restore or any of that jazz. You now have the blueprint, now you can replicate this knowledge onto other shares/datasets. This way you can give other users access with their own creds and allow or disallow them to specific shares via the groups. Certainly you are on the right track.

Not to question your suggestion of groups, users, and permissions, but I am curious why you make the suggestion you do? It's one thing to have an answer, but I want to understand the reasoning behind it as well.

I was preforming your instructions when I was attempting prior to your help, but I was forgetting to uncheck the "Default Permissions" I believe.

Restarting smbd is always a good idea after meddling with your shares. I forgot to include this in the instructions, apologies. Glad everything is starting to work out for you. Good luck!

I hadn't had to do this prior that I could recall but it made sense to restart the service when I noticed things weren't playing nice. I work primarily in the Windows world, but my experience with Linux/FreeBSD have taught to restart services after playing with them.

 

[JohnDigital]

Its just a matter of tidiness for me. Having a group for every user/dataset is overkill imho. I have only my group and media. Every user is in the group media and my user is also in JBD, wheel, media. Then the different users are all able to login with their user:pass and there are no other hoops to jump through with dataset permissions because media is group owner on all my datasets that are shared. I also have a guest account with full blown 777 perms on my guest dataset, and that is where I keep things for all users who need to access, isos, softwares and such. Its just my preference and it keeps things tidy. Its also more in line with how its intended to be used. Ultimately its my preference and by no means the only way to do it.

 

[SCS]

Well Thank You again.