Bug 10362 - Does not honor default ACL on Solaris
Does not honor default ACL on Solaris
Status: RESOLVED DUPLICATE of bug 10492
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services
4.1.5
All Solaris
: P5 normal
: ---
Assigned To: Volker Lendecke
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-01-07 17:02 UTC by Tom Schulz
Modified: 2014-03-19 17:45 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Schulz 2014-01-07 17:02:07 UTC
This likely is also a problem in Samba 4.*, but I am not in a position to test that.
We are running Samba on a Solaris 10 system. When creating directories (folders) and files in a directory with a default ACL set up, the default ACL is not used.

For instance, for a share set up with 'inherit acls = yes' and an ACL as follows:
# file: .
# owner: schulz
# group: users
user::rwx
group::rwx              #effective:rwx
mask:rwx
other:r-x
default:user::rwx
default:group::rwx
default:mask:rwx
default:other:r-x

A new folder created through Samba ends up with an ACL as follows:
# file: foom4
# owner: schulz
# group: users
user::rwx
group::r-x              #effective:r-x
mask:r-x
other:r-x
default:user::rwx
default:group::rwx
default:mask:rwx
default:other:r-x

And permissions drwxr-sr-x+

Note that the read permission is not set for group. I can get the behavior I need in this case by adding 'inherit permissions = yes' to the share, but that only works if the parent directory has the same permissions as that desired for the new directory.
Comment 1 Tom Schulz 2014-02-25 16:12:42 UTC
I have just verified that this problem does exist on Samba 4.1.5

Also, this line from my previous comment:
> Note that the read permission is not set for group.
Should read:
Note that the write permission is not set for group.
Comment 2 Tom Schulz 2014-03-17 19:51:07 UTC
This bug will be fixed by the fix for Bug 10492
Comment 3 Björn Jacke 2014-03-19 17:45:27 UTC

*** This bug has been marked as a duplicate of bug 10492 ***