Provided by: netatalk_2.1.2-2_i386
afp_acls - Setup and Usage Howto for ACLs with Netatalk
ACL support for AFP is implemented with NFSv4 ACLs. Few filesystems and
fewer OSes support these. At the time of implementation its only
provided with ZFS on Solaris, Opensolaris and derived distributions.
In order to be able to support ACLs, the following things have to be
1. ZFS Volumes
You MUST configure two ACL parameters for any volume you want to
use with Netatalk:
aclinherit = passthrough
aclmode = passthrough
For an explanation of what these parameters mean and how to apply
them see, your hosts ZFS documentation (e.g. man zfs).
2. Authentication Domain
Your server and the clients must be part of a security association
where identity data is coming from a common source. ACLs in Darwin
are based on UUIDs and so is the ACL specification in AFP 3.2.
Therefor your source of identity data has to provide an attribute
for every user and group where a UUID is stored as a ASCII string.
In other words:
· you need an Open Directory Server or an LDAP server where you
store UUIDs in some attribute
· your clients must be configured to use this server
· your server should be configured to use this server via
nsswitch and PAM.
This however is not a strict requirement: if you create
duplicates of every LDAP/OD user and group with identic
attributes (name, uid, gid) in your local data store
(/etc/[passwd|group]) ACLs will work as long as user/group
names/ids in the filesystem are equal to their counterparts
in the LDAP/OD datastore.
· configure Netatalk via afp_ldap.conf so that Netatalk is able
to retrieve the UUID for users and groups via LDAP search
3. Netatalk Volumes
Finally you can add options:acls to your volume defintion to add
ACL support. In case your volume basedir doesn´t grant read
permissions via mode (like: 0700 root:adm) but only via ACLs, you
MUST add the nostat option to the volume defintion.