cifs share not allowing applications write permission?

[JJD]

I just setup a new freenas system and keep running into an issue I have never had before.
The network has both windows and osx clients so I am using linux acl's and the contents of my zfs data set have 777 permissions right now. From my windows clients I can copy files to the share (in explorer) but if I am in an application I get "permission denied" if I try to save directly to the share. I have tested this with outlook (saving attachments), word, and excel.

I copied the data into my dataset from a windows share.

I tried to search for a solution but either my search terms were wrong or it's not a common issue.

 

[dlavigne]

Which version of FreeNAS? Does changing to Windows ACLs fix the issue?

 

[JJD]

I'm running 9.2.1. changing to windows ACLs does not fix the issue after changing I have set permissions for all files from in windows to allow everything for every one and no change... I tested this by creating a new dataset and rsyncing all the data over to it then setting to windows ACLs

 

[dlavigne]

There were several permission bugs that were fixed in 9.2.1.2 which was released yesterday. Let us know if you still have permission issues after upgrading.

 

[cpjolicoeur]

I'm having the same issues. I upgraded to 9.2.1.2 and still not working.

I have a volume shared where users who are in the group can't write to the directory or create new files.

 

[elforesto]

I'm seeing the same as the user above. I had previously done a manual fix for this issue on 9.2.1.1 which seems to have been reverted in 9.2.1.2.

See: https://bugs.freenas.org/issues/4151#note-17

Seems like if an update is going to automagically break it, there should be a way for it to fix it that doesn't involve a workaround.

 

[cpjolicoeur]

@elforesto, care to share your manual fix? I read the bug-thread but I'm not strong with Samba and I'm not 100% sure of what you actually did or need to do to fix the issue and give users write permissions like expected.

 

[elforesto]

Same issue here. I previously used a workaround from Bug #4151 (see: https://bugs.freenas.org/issues/4151#note-17) but that doesn't seem to provide relief anymore.

Edit: I followed the setfacl commands to manually update the ACLs. No dice now. It worked in 9.2.1.1.

 

[John Hixson]

Same issue here. I previously used a workaround from Bug #4151 (see: https://bugs.freenas.org/issues/4151#note-17) but that doesn't seem to provide relief anymore.

Edit: I followed the setfacl commands to manually update the ACLs. No dice now. It worked in 9.2.1.1.

So some things have changed with the update to Samba 4. ACL's are pickier than they were previously. If you "chmod 777" a directory or file, it's not going to do what you think it is in the world of windows. For sharing for UNIX systems, you are fine. Let me give an example. I will create a dataset of type "UNIX" named FOO1, and a dataset of type "Windows" FOO2. Let's look at permissions *without* setting them from the permissions wizard now:

FOO1:

[root@raidzilla64 /mnt/vol0]# ls -ld FOO1
drwxr-xr-x 2 root wheel 2 Mar 4 10:38 FOO1
[root@raidzilla64 /mnt/vol0]# getfacl FOO1
# file: FOO1
# owner: root
# group: wheel
owner@:rwxp--aARWcCos:------:allow
group@:r-x---a-R-c--s:------:allow
everyone@:r-x---a-R-c--s:------:allow
[root@raidzilla64 /mnt/vol0]#


FOO2:

[root@raidzilla64 /mnt/vol0]# ls -ld FOO2
drwxrwxr-x+ 2 root wheel 3 Mar 4 10:39 FOO2
[root@raidzilla64 /mnt/vol0]# getfacl FOO2
# file: FOO2
# owner: root
# group: wheel
owner@:rwxpDdaARWcCos:fd----:allow
group@:rwxpDdaARWcCos:fd----:allow
everyone@:r-x-D-a-R-c---:fd----:allow


See the '+' at the end of the permission string for FOO2? That indicates this entry is using an ACL. Also, see the difference in the ACL entries? The windows one by default "does the right thing". This ACL says that owner and group have "full access" while everyone else has "read access". This is only for newly created windows datasets since 9.2.1.2. If you want to change behavior or permissions on datasets that already existed, you'll have to do so manually. Let's see what happens when we "chmod 777" the FOO2 dataset:


[root@raidzilla64 /mnt/vol0]# chmod 777 FOO2
[root@raidzilla64 /mnt/vol0]# getfacl FOO2
# file: FOO2
# owner: root
# group: wheel
owner@:rwxp--aARWcCos:------:allow
group@:rwxp--a-R-c--s:------:allow
everyone@:rwxp--a-R-c--s:------:allow
[root@raidzilla64 /mnt/vol0]# ls -ld FOO2
drwxrwxrwx 2 root wheel 3 Mar 4 10:39 FOO2


Oh no! It took away some of our ACL access permissions! It's not "full access" anymore. See what is happening here? I'm going to cut and paste the ACL access permissions here directly from the man page from setfacl to hopefully clarify some of this:


access permissions

Access permissions may be specified in either short or long form.
Short and long forms may not be mixed. Permissions in long form
are separated by the `/' character; in short form, they are con-
catenated together. Valid permissions are:
Short Long

r read_data
w write_data
x execute
p append_data
D delete_child
d delete
a read_attributes
A write_attributes
R read_xattr
W write_xattr
c read_acl
C write_acl
o write_owner
s synchronize

In addition, the following permission sets may be used:

Set Permissions
full_set all permissions, as shown above
modify_set all permissions except write_acl and write_owner
read_set read_data, read_attributes, read_xattr and read_acl
write_set write_data, append_data, write_attributes and
write_xattr


Windows needs more than a "chmod 777" to work right. So my advice is to NOT change permissions on newly created windows datasets and manage the permissions from windows once created, and on existing datasets that are used for windows sharing, to either leave permissions alone, modify them via windows, or use setfacl on FreeNAS to fix any issues you are having instead of chmod.

For further reference on setfacl, here is the online man page:

http://www.freebsd.org/cgi/man.cgi?query=setfacl&apropos=0&sektion=0&manpath=FreeBSD 9.2-RELEASE&arch=default&format=html

I hope this helps!

 

[elforesto]

Thanks, John. That is certainly helpful, though I seem to still be having issues.

The volume in question has ownership of nobody:media with 777 permissions. I used setfacl to grant modify_set to owner and group and read_set to everyone with the following commands:

Code:

setfacl -m owner@:modify_set:fd:allow TV_Shows
setfacl -m group@:modify_set:fd:allow TV_Shows
setfacl -m everyone@:read_set:fd:allow TV_Shows

I verified that the ACLs are set as expected:

Code:

[root@freenas] /mnt/main# getfacl TV_Shows
# file: TV_Shows
# owner: nobody
# group: media
            owner@:rwxpDdaARWc--s:fd----:allow
            group@:rwxpDdaARWc--s:fd----:allow
        everyone@:r-----a-R-c---:fd----:allow

When I use an account that has media as an auxiliary group, I get "permission denied" errors when I attempt to update a file I've created. I'm left scratching my head, especially since the file itself seems to have the right ACL and is 777:

Code:

[root@freenas] /mnt/main/TV_Shows/How I Met Your Mother/Season 9# getfacl How.I.Met.Your.Mother.S09E19.HDTV.x264-EXCELLENCE.mp4
# file: How.I.Met.Your.Mother.S09E19.HDTV.x264-EXCELLENCE.mp4
# owner: nobody
# group: media
            owner@:rwxp--aARWcCos:------:allow
            group@:rwxp--a-R-c--s:------:allow
        everyone@:rwxp--a-R-c--s:------:allow

I've already tried bouncing CIFS to see if it just needed to re-read its configuration, but there's been no change. Any ideas?

As an aside, while I don't mind getting into the command line weeds when needed, it seems like this is something that should be handled by the GUI more gracefully than it is.

 

[John Hixson]

Thanks, John. That is certainly helpful, though I seem to still be having issues.

The volume in question has ownership of nobody:media with 777 permissions. I used setfacl to grant modify_set to owner and group and read_set to everyone with the following commands:

Code:

setfacl -m owner@:modify_set:fd:allow TV_Shows
setfacl -m group@:modify_set:fd:allow TV_Shows
setfacl -m everyone@:read_set:fd:allow TV_Shows

I verified that the ACLs are set as expected:

Code:

[root@freenas] /mnt/main# getfacl TV_Shows
# file: TV_Shows
# owner: nobody
# group: media
            owner@:rwxpDdaARWc--s:fd----:allow
            group@:rwxpDdaARWc--s:fd----:allow
        everyone@:r-----a-R-c---:fd----:allow

When I use an account that has media as an auxiliary group, I get "permission denied" errors when I attempt to update a file I've created. I'm left scratching my head, especially since the file itself seems to have the right ACL and is 777:

Code:

[root@freenas] /mnt/main/TV_Shows/How I Met Your Mother/Season 9# getfacl How.I.Met.Your.Mother.S09E19.HDTV.x264-EXCELLENCE.mp4
# file: How.I.Met.Your.Mother.S09E19.HDTV.x264-EXCELLENCE.mp4
# owner: nobody
# group: media
            owner@:rwxp--aARWcCos:------:allow
            group@:rwxp--a-R-c--s:------:allow
        everyone@:rwxp--a-R-c--s:------:allow

I've already tried bouncing CIFS to see if it just needed to re-read its configuration, but there's been no change. Any ideas?

As an aside, while I don't mind getting into the command line weeds when needed, it seems like this is something that should be handled by the GUI more gracefully than it is.

And what happens if you set "full_set" for group? Can you try that and verify if it works?

 

[elforesto]

That didn't seem to affect it.

Curiously, I tried to create a new file (instead of writing to the existing one) and it worked. I removed the existing file and allowed it to be recreated and now it can be written to. It seems like the ACL is only having an effect on new files but none on existing files. Quite strange, no?

 

[John Hixson]

That didn't seem to affect it.

Curiously, I tried to create a new file (instead of writing to the existing one) and it worked. I removed the existing file and allowed it to be recreated and now it can be written to. It seems like the ACL is only having an effect on new files but none on existing files. Quite strange, no?

Ok, this is a different situation. Modifying a file requires different access permissions. Refer to the online man page depending on what you want to do ;-) You do need append and write permissions though.

 

[elforesto]

I would have thought that applying both modify_set and full_set would have affected the existing files, though. They include both the write and append permissions. Am I missing something?

 

[John Hixson]

I would have thought that applying both modify_set and full_set would have affected the existing files, though. They include both the write and append permissions. Am I missing something?

Are you applying these permissions only to *the directory*? using setfacl, the permissions will not magically propagate to all other files and directories that exist already. You will have to do this manually on everything (or write a script, or use with find and xargs, etc).

 

[John Hixson]

Are you applying these permissions only to *the directory*? using setfacl, the permissions will not magically propagate to all other files and directories that exist already. You will have to do this manually on everything (or write a script, or use with find and xargs, etc).

And unfortunately, setfacl does not have a -R switch

 

[elforesto]

And unfortunately, setfacl does not have a -R switch

Ugh. Hopefully this is something to be addressed via the GUI or system scripts in a future release? This is a major pain point.

 

[John Hixson]

Ugh. Hopefully this is something to be addressed via the GUI or system scripts in a future release? This is a major pain point.

Well, the idea is that when you create a new windows dataset, that you manage permissions from windows. So all new files and directories will inherit permissions correctly as set from start. However, this does not change existing shares. Existing shares will need to be modified (if necessary, but should work correctly). In the UI, in the permissions wizard, if you select "windows/mac" and do a recursive permission change, it will set *all files and directories* to have full access for owner and group, and read access for everyone else. That is an option for people who want to do that. Otherwise, for any other kind of fine grained control, you'll need to resort to the command line or windows to change permissions.

 

[elforesto]

I'm using UNIX permissions. The box that's been having access issues runs Ubuntu 12.04 LTS.

At any rate, it was working in 9.2.0 and was then broken. I don't think it's an unreasonable expectation that it should work as it previously did after an upgrade. It's also confusing that getfacl shows the expected ACLs on the file and yet those are not the applied permissions. I think there's something else going on that probably needs to be looked at, possibly only affecting upgrades and not new deployments.

It probably would have been a good idea to put Samba 4 into a major release (like 9.3) instead of a point release. My fault for not understanding the implications of the migration, but I certainly would have done more research on something that's a major release.

 

[cpjolicoeur]

John, thx so much for the time and help on this. I was able to fix my existing data set and permissions are working as I intend now.