Broken when Windows ACL is selected

[John M. Długosz]

On the "Change Permission" dialog box, if the "Type of ACL" is set to Windows, it doesn't work. Pressing [change] shows a banner that all went well, but nothing changed which you can see if you bring up the box again.

In the console log, it shows what I interpret to mean that winacl.sh was called with incorrect arguments.

This is FreeNAS-9.1.1-RELEASE-x64 (a752d35)

 

[dlavigne]

Define "doesn't work".

Post the relevant part of the console log using code blocks.

 

[John M. Długosz]

Define "doesn't work".

Read the next sentence and beyond. This statement was a summary, the "topic sentence" of the paragraph.

Post the relevant part of the console log using code blocks.

Code:

Oct  9 13:17:12 freenas notifier: Usage: /usr/local/www/freenasUI/tools/winacl.sh [options] ...
Oct  9 13:17:12 freenas notifier: Where option is:
Oct  9 13:17:12 freenas notifier:     -o 
Oct  9 13:17:12 freenas notifier:     -g 
Oct  9 13:17:12 freenas notifier:     -p 
Oct  9 13:17:12 freenas notifier:     -f 
Oct  9 13:17:12 freenas notifier:     -d 
Oct  9 13:17:12 freenas notifier:     -r
Oct  9 13:17:12 freenas notifier:     -v

 

[dlavigne]

I asked because it wasn't clear. Are you saying that if you open this config screen again it is reset back to the original?

 

[John M. Długosz]

re: " but nothing changed which you can see if you bring up the box again. "

I asked because it wasn't clear. Are you saying that if you open this config screen again it is reset back to the original?

Yes, exactly. It still shows root/wheel in my case, when I had changed it to (say) nobody/share.

 

[dlavigne]

In that case, you should see if a bug already exists at https://bugs.freenas.org/projects/freenas and create one if it does not.

 

[John M. Długosz]

Is anyone else using Windows ACL (successfully) in this version? It surprises me that it has not been noticed before.

 

[Myth]

I'm running into the same problem. It seems that the command that FreeNAS is executing is wrong.

I tried to manually run .../winacl.sh -o administrator -g dusers -p /mnt/storage/ -r but I still can't change the permissions from Windows.

 

[kevanbrown]

I actually tried running the command myself as well and found that it worked for me. I'm wondering if the GUI isn't correctly handling the spaces in group names, etc. when calling the command. I ran the following command and it succeeded:

/usr/local/www/freenasUI/tools/winacl.sh -o administrator -g "domain admins" -p /mnt/zfsint3

 

[Myth]

Are you able to modify the permissions of a shared CIFS? Can you add a user to a share?

 

[John M. Długosz]

kevanbrown, I'm not on a domain or AD, and the group names never have spaces in them. The initial value is “wheel”, and the group I created is simply called “share”

Myth, there doesn't seem to be any permissions associated with the Share itself, like there are with making a directory visible from a Windows machine. I just set the desired permissions on the directory being shared.

 

[kevanbrown]

Myth, to answer your question, yes, I was able to modify the permissions. I actually have FreeNAS 9.1.1 joined to an Active Directory domain. I have a ZFS volume with UNIX permissions, and inside that volume I have a ZFS dataset with Windows permissions. I have the owner of the ZFS dataset set to "administrator" and the owning group set to "domain admins". After changing the owner and owning group in the UI, I went back in and change the permissions model for the ZFS dataset to "Windows". I tried to access the CIFS share as the domain "administrator" account and failed. I manually ran "/usr/local/www/freenasUI/tools/winacl.sh -o administrator -g "domain admins" -p /mnt/zfsint3/SharedMedia -r" after which I was able to successfully access the share and set the permissions on the share root from within my Windows client.

So there is definitely a bug somewhere in the UI as to how it is calling winacl.sh.

 

[John M. Długosz]

If Windows ACL is just a superset of Unix ACL, adding some unspecified features that I have not missed yet, why would your share not work without Windows permissions? Is it an AD-friendly thing?

Looking through the winacl.sh script, I don't even see it changing the dataset to a different "mode" of what kind of ACL it supports.

 

[kevanbrown]

I assume that it didn't work because the ACL was improperly structured or didn't include the correct ID for the synchronized AD user or group that was in the Windows ACL. Otherwise, why would it work after manually running the command? I'm just describing the symptoms of whatever is the underlying problem, and the workaround that proved successful for my configuration.

 

[mauirixxx]

Just wanted to say thanks for this. After struggling to just get AD to WORK (my main admin account had a % symbol as part of the password, used a different account with only letters & numbers) I then struggled with CIFS. If I enabled home directories, users could write all day long to that, but not the actual CIFS share I created. We could see it, no problem ... just couldn't do anything useful with it.

Running the winacl script manually did the trick. THANK YOU! <3

 

[John M. Długosz]

I still want to know (on this thread or the other I posted the question on) what setting Windows ACL actually does.

 

[Myth]

It allows you to control the permissions from Windows. When you right click Properties -> Security and you're able to change what a user, group or everyone can do (read, write, ...). Otherwise you can manage it from Unix. Unix ACL is simpler than Windows ACL, but you can always use ZFS ACL which is extended as well (getfacl / setfacl).

This is especially important if FreeNAS is part of a domain.

 

[John M. Długosz]

It allows you to control the permissions from Windows. When you right click Properties -> Security and you're able to change what a user, group or everyone can do (read, write, ...).

I'm doing that just fine with ACL left as Unix. As I reported on another thread, the initial values didn't match what Windows recognizes for the simple summary, and they are not set to inherit. But I changed them around on the top directory to be what Windows does, and everything worked just fine.

The user/group/everyone is not ACL. From what I gather, zfs supports NFSv3 ACLs. There is no setting for "none", just ACL as Unix or Windows. So I'm supposing that the classic permission bits are translated into an ACL with the same meaning when an ACL is fetched.

 

[mauirixxx]

maybe we should file this as a bug report?

 

[John M. Długosz]

maybe we should file this as a bug report?

The inability to set Windows ACL as a bug report was filed as issue #3305, and since fixed by John Hixson for the 9.1.2 release. Maybe that feature should be tested before release, too. As for something else about my most recent message being a bug, I still don't know what it's supposed to do.