Bitten By Bug #4151

[Christian Lahti]

Hey guys:

I have been bitten by the bug #4151 "CIFS all files appear as readonly for non-owners". Here is my update to the bug:

Hey guys:

I am having this exact same issue after upgrading to FreeNas 9.2.1. We have a 34TB file store with hundreds of thousands of files, hooked up to Active Directory. After the upgrade all files are opened read-only if the owner of the file is someone else. Here is an example recipe of a share that used to work in 8.x:

ZFS Volume Settings:
- volume name: CS_Share
- owner: nobody
- group: cs (AD group)
- mode: 770
- Type of ACL: Windows/Mac
- Set permissions recursively: unchecked

Samba Share Settings:
- Share Name: CS_Share
- Comment: Customer Service Share
- Path: /mnt/vol0/CS_Share
- Export Read Only: unchecked
- Browsable to Network Clients: checked
- Inherit Owner:
- Inherit Permissions:
- Inherit ACL's:
- Export Recycle Bin:
- Show Hidden Files:
- Allow Guest Access:
- Only Allow Guest Access:
- (Advanced) Auxiliary Parameters:
valid users = @cs @"domain admins"
force group = @cs
create mask = 02770
directory mask = 02770
force create mask = 02770

We would then go to the unix file system and recursively set /mnt/vol0/CS_Share:

chgrp -R cs /mnt/vol0/CS_Share
chmod -R 02770 /mnt/vol0/CS_Share

The effect of all of this is that members of group cs have read-write, members of "Domain Admins" have read-write, all others are denied. The permissions on directories get 02770 and the permissions on files get 0770. Now only owners of files have read-write, others in cs and Domain Admins can open the files but it is read-only. Can someone please give me the recipe and the exact steps necessary to change and fix this in the new version of FreeNas 9.2.1? This is killing us at the moment.

Thanks!

Addendum:

I tried this from another comment in the bug:
find /mnt/vol0/CS_Share -type d -exec setfacl -m owner@:full_set:fd:allow,group@:modify_set:fd:allow {} \;
find /mnt/vol0/CS_Share -type f -exec setfacl -m owner@:full_set::allow,group@:modify_set::allow {} \;

The result is that now non-owners can now open files read-write, but new files created get the permission:

ls -al Test.txt
---xr-x---+

getfacl Test.txt
# file: Test.txt
# owner: clahti
# group: cs
owner@:r-------------:------:deny
group:nobody:rwxpDdaARWcCo-:------:allow
owner@:--x---aARWcCos:------:allow
group@:r-x---a-R-c--s:------:allow
everyone@:------a-R-c--s:------:allow
Resulting in *nobody* being able to open that file subsequently.

 

[Christian Lahti]

another update:

running the facl commands above still results in non-owners not being able to edit, open yes but not save.

 

[clahti]

I really cannot believe nobody else is having this issue en-mass, I have researched for two days to no avail. I am sure reasonably I am missing something simple and/or stupid, reading setfacl man page makes no sense to me at all. Plus many commands in examples do not work, for example I get "there are no default entries in NFSv4 ACLs". Can someone tell me how to setup a share like this please please? whatever combination of GUI/cmd line steps are necessary:

• Share Name: TestShare
• AD Group TestWUsers: read/write
• AD Group TestRUsers: read-only
• AD Group Domain Admins: read/write

It should be so simple but I cannot get this scenario to work as expected, and have been beating on this for two days. We upgraded from 8.3.x to 9.2.1, I am very willing to go back to 9.2.0 but how would I do this? The natives are going to revolt...

 

[Yatti420]

Which FreeNAS version?

 

[clahti]

we upgraded from 8.3.x to 9.2.1.2

 

[clahti]

assuming I do this on all relevant shares:

find /mnt/vol0/path-to-share -type d -exec setfacl -m owner@:full_set:fd:allow,group@:modify_set:fd:allow {} \;
find /mnt/vol0/path-to-share/ -type f -exec setfacl -m owner@:full_set::allow,group@:modify_set::allow {} \;

what are the exact GUI settings I should set? From what I gather it should be:

Inherit Owner: unchecked
Inherit Permissions: unchecked
Inherit ACL's: checked

Is this correct? Also the ZFS dataset should be set to "windows" and not unix. I think I have tried every possible combination, the best I have been able to produce is that existing files get fixed, but newly created files still have the problem. This used to be fixed by setting the group sticky bit in samba3 land, but that does not seem to help for samba4.

 

[Nathan_S]

I've run into the same issue. Fairly basic configuration, nothing "special" about it really. Not on a VM, not a single jail. We upgraded from 9.2.0 to 9.2.1.2. We use CIFS primarily, as we have OSX, Windows, and Unix machines sharing files together and it seems the happiest for that use. We also have a NFS share that gets used for our proxmox VM machines.

I'm in the middle of rolling back to 9.2.0 right now, and will be looking forward to an update so hopefully I can get this upgrade working correctly asap, as I'm really looking forward to the samba upgrade.

 

[Nathan_S]

We fixed our issue with our freenas box.

Our problem was related to the fact that ACL file permissions were completely jacked. I'm unsure if they were messed up the whole time and the older version of samba didn't care, or if somehow in the upgrade ACL's got messed up then. At any rate, we ran this command against all our CIFS share paths, and all is well.

find /mnt/<path-to-share>/ -type f -exec setfacl -m owner@:full_set::allow,group@:modify_set::allow {} \;

This fixes all existing files in the share directory.

find /mnt/<path-to-share> -type d -exec setfacl -m owner@:full_set:fd:allow,group@:modify_set:fd:allow {} \;

This fixes all directories in a share, and the share itself (note the lack of "/" at the end of the file path). If you have your options set to "inherit ACL" then all new files should be able to be appended.

Hope this helps someone else out.

 

[pce]

We fixed our issue with our freenas box.

Our problem was related to the fact that ACL file permissions were completely jacked. I'm unsure if they were messed up the whole time and the older version of samba didn't care, or if somehow in the upgrade ACL's got messed up then. At any rate, we ran this command against all our CIFS share paths, and all is well.

find /mnt/<path-to-share>/ -type f -exec setfacl -m owner@:full_set::allow,group@:modify_set::allow {} \;

This fixes all existing files in the share directory.

find /mnt/<path-to-share> -type d -exec setfacl -m owner@:full_set:fd:allow,group@:modify_set:fd:allow {} \;

This fixes all directories in a share, and the share itself (note the lack of "/" at the end of the file path). If you have your options set to "inherit ACL" then all new files should be able to be appended.

Hope this helps someone else out.

THANK YOU Nathan_S!

My half head of grey hair nearly went full head...

 

[pce]

If it's not already there, I think that this particular problem/solution should be highlighted in the upgrade guide...

 

[LAYGO]

We fixed our issue with our freenas box.

Our problem was related to the fact that ACL file permissions were completely jacked. I'm unsure if they were messed up the whole time and the older version of samba didn't care, or if somehow in the upgrade ACL's got messed up then. At any rate, we ran this command against all our CIFS share paths, and all is well.

find /mnt/<path-to-share>/ -type f -exec setfacl -m owner@:full_set::allow,group@:modify_set::allow {} \;

This fixes all existing files in the share directory.

find /mnt/<path-to-share> -type d -exec setfacl -m owner@:full_set:fd:allow,group@:modify_set:fd:allow {} \;

This fixes all directories in a share, and the share itself (note the lack of "/" at the end of the file path). If you have your options set to "inherit ACL" then all new files should be able to be appended.

Hope this helps someone else out.

HOLY SMOKES! FINALLY! I too was about to pull my hairs out! THANK YOU!

What a relief . . .

 

[Nathan_S]

I'm glad to see others found some solace in our findings.

Fast forward a bit I just wanted to update the forums with the data point that we ran into this issue MULTIPLE times, until we nailed down which user was causing it. Couldn't find anything wrong on the client side, and when using the same user from another client machine files would still go pear shaped. We created a fresh user, and have not had a SINGLE problem since. No setting was different between the user. Not sure what caused the bug, nor could I track down a perfect way to recreate it every time. But it was definitely related to that user account.