Verification that I didn't break or corrupt anything by recursively changing permissions mode

[laungst]

specs: AMD A10-7860k, 16RAM, 8x8TB HDDs, FreeNAS-11.1-U2

I've been using freenas for ~3 years now with old hardware I had laying around and I've loved it so far- haven't had any issues I couldn't overcome through research on this forum and others like it until now.

I have a mostly full ~50TB freenas volume after raid-z1, and I'm about to expand with another ~50TB freenas volume in the same system. Because of this expansion, I was cleaning up a bit- re-setting up alerts, accounts, permissions, etc. in ways that make more sense and that are more secure now that I understand freenas a bit better than when I started.

As part of this, in

Code:

Storage > Volumes > [volume name] > [dataset name] > Change Permissions

I changed Permission Type from Windows to Unix so I could un-check 'other' and 'group' so that only I (the owner of the dataset) could access that dataset, and no one else in my group could (if Windows is selected instead of unix, it greys out those selection boxes and forces 'group' and 'other' read and execute to be checked). I also checked the 'Set permission recursively' box so that it would change it for the entire dataset.

Upon clicking 'Change', freenas used disks at 100% for ~10 minutes, and in the log gave:

Code:

chmod: [file path]: Operation not permitted

essentially denying the change for seemingly every single file in the dataset. I'm not sure how many lines it was, but it took quite a few minutes to scroll through them all holding the 'page down' key in putty. I'm assuming hundreds of thousands if not millions.

After doing more research on this forum, apparently starting with freenas 9 it was impossible for someone to recursively set permissions from Windows to Unix because it would corrupt almost everything. I also read on another post that the only way to do this would to be create another dataset then migrate the data over. I can't find either of those posts now, but here is one that says permission type

> "is best defined initially and not changed, otherwise the results won't be pretty."

Essentially, my questions are:

1. This action wouldn't have corrupted any of my data or is going to cause me any problems in the future, is it? I don't think it did, I'm asking just to be 100% sure before I ever update my backup, and also because I obviously can't read though every line in that massive log.

2. Why is it that when 'Windows' permission mode is selected (shown in the image below)

"Group, and Other" are grayed-out and force-checked? Does this mean that anyone in 'wheel' can read/write/execute to it and anyone else with any credentials can read/execute? Before the entire system was just for me, but part of this expansion was adding others in my house, and allowing everyone read access to my dataset wouldn't be acceptable.

3. If #2 is the case and everyone is allowed read access, do I have any other options?

Any help with any of would be greatly appreciated.

 

[anodos]

What version of FreeNAS is this?

 

[laungst]

What version of FreeNAS is this?

FreeNAS-11.1-U2

 

[anodos]

There's not an easy way to do what you want from the UI. If you recursively chmod (what you're trying to do), then it will probably end up breaking permissions.
To remove it from the command line, you can do the following

Code:

find /mnt/Volume1/pepperoni | setfacl -x everyone@::allow

Disclaimer: you assume full responsibility for the results of running that command and removing the permission. I don't know anything about your environment or whether that's a wise course of action. execute rights are required for directory traversal. So with that change only "luke" and members of "wheel" will be able to traverse to paths under "pepperoni".