I found a strange behaviour running samba 3.0.13 on aix 4.3. When I add users or
group access rights (rwx) to the underlying directory using the acls of jfs
through samba, I can create an edit a file in this directory. When I want to
delete or rename that file, I get an access denied. The user or group I added to
the directory is a user out of ADS. The AIX machine is a AD-Member-Server and
the users are locally known through the security - methods.cfg. It would be
very nice to hear from you soon, cause the machine should go productive next week.
Thanks in advance, regards Alex.
Same problem, AIX 4.3.3 with samba-3.0.13
I'll try to rollback the patch applied for the bug report #2521
the bug is not from Revision 6003 of smbd/posix_acl.c
samba-3.0.11 doesn't has this bug
You *must* configure smbd with --with-acl-support to be able to successfully
process ACLs with 3.0.13 and above.
(In reply to comment #3)
> You *must* configure smbd with --with-acl-support to be able to successfully
> process ACLs with 3.0.13 and above.
I configured it with the --with-acl-support option. As I wrote I can set acls
but the don't work properly ( -> description). In samba 3.0.11 everything works
fine, thanks Yannick.
In that case please post a debug level 10 log as an attachment to this bug
report showing the access failure.
(In reply to comment #5)
> In that case please post a debug level 10 log as an attachment to this bug
> report showing the access failure.
excuse me for answering that late. I'm not allowed to post any log files due to
security reasons. Can anyone else please post the log (Yannick Bergeron?) ???
I have the same problem with Samba 3.0.13 and 3.0.12 under SUN Solaris 8.
I configure smbd with --with-acl-support but it doesn't work, so I go back to
version 3.0.11. That works fine.
Same problem here,
What we see is degeneration between posix_acls.c versions 4348 and 6003.
Diff for /branches/SAMBA_3_0_RELEASE/source/smbd/posix_acls.c between version
4348 and 6003
version 4348, Thu Dec 23 18:45:36 2004 UTC version 6003, Wed Mar 23 19:41:
56 2005 UTC
Namely can_delete_file_in_directory() appears to check only for tradional unix
ownerships and group acls. It doesn't account for deletion rights coming from
E.g. if running getfacl on a directory gives on user (owner) ACL such as:
This means in underlying operating system (Solaris) that this addional user
(not tradional UNIX owner in stat buf), in this case sanna, should be able to
delate files in this directory.
As the check is written currently, sanna is not able to delete any files she or
others have created in the directory since 'user ACLs' are not checked.
Reverting this change from 3.0.13 version to 3.0.11 version fixes the problem
I opened bug #2711, that look same like this ? If so, so I can provide all
required logs in required level.
Looks like general problem ?...
This sounds like it is fixed in r6378
James says fixed.