Good news, I took a closer look with wireshark, read up about AFP permissions, and trudged through the source code and found my problem.

As far as POSIX ACLs and group membership is concerned, I discovered Netatalk does the permission mapping by looking up the groups the user belongs to and seeing if permission is granted by any of the ACEs. That lead me to find that my winbind was broken and not expanding nested groups. As a test, I added a user to the group directly and Finder began allowing writes.

Would it make more sense to use access() to determine what permissions the user has?

Now I just need to get to the bottom of the winbind issue...

Many thanks for getting me in the right direction!


On Thu, May 15, 2014 at 1:40 PM, Ralph Böhme <rb@netafp.com> wrote:

Am 15.05.2014 um 18:09 schrieb Ryan Bair <ryandbair@gmail.com>:

> The ACLs presented in the Finder window appear correct.
>
> Interestingly, if I `ls -led` in a directory I see:
>
>  0: ABCDEFAB-CDEF-ABCD-EFAB-CDEF000003F4 allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,file_inherit,directory_inherit,only_inherit
>  1: ABCDEFAB-CDEF-ABCD-EFAB-CDEF000003F4 allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity
>
> The ABCDEFAB-CDEF-ABCD-EFAB-CDEF000003F4 is a bogus looking UUID but `afpldaptest -u` does resolve it to the correct name. It also resolves the correct uuid (as found in AD) to the proper name as well.

hey, that's not bogus, it actually took quite some time and effort to learn about these special computed UUIDs for users and groups that come from a datasource that lacks a proper UUID attribute. :)))

> Could I have a stale cache somewhere causing netatalk to pass incorrect UUIDs?

no and no. :)  You're issue is probably something else (the effective permission mapping code in Netatalk -- ah, I hate that stuff).

Cheers!
-r