Issue #1: Rsync is dropping ACLs
After applying the ACL permissions you need to take care that when you perform your rsync that you're using either the -A or --acls switch. This instructs rsync to make sure to preserve these when doing the sync.
excerpt from rsync man page
-A, --acls preserve ACLs (implies -p)
Issue #2: No ACL permissions
In looking at your example it does contain permissions as follows.
traditional perms
# owner: stian
# group: admin
user::rwx
group::r-x
other::r-x
ACLs
default:user::rwx
default:user:www-data:rwx
default:group::r-x
default:mask::rwx
default:other::r-x
But these ACLs are for the creation of new objects, and don't work exactly the way you think. You need to still create an entry for user www-data in addition to the default ACL perms.
Example
$ pwd
/tmp/somedir
$ mkdir data
$ setfacl -R -d -m u:gopher:7 data
$ getfacl data
# file: data
# owner: root
# group: root
user::rwx
group::r-x
other::r-x
default:user::rwx
default:user:gopher:rwx
default:group::r-x
default:mask::rwx
default:other::r-x
An experiment
Now let's try and write a file to the data directory as user gopher.
$ sudo -u gopher touch /tmp/somedir/data/afile
touch: cannot touch `/tmp/somedir/data/afile': Permission denied
Look familiar?
Adding additional ACL permissions
It's because you need to add a ACL for the user www-data, the default rules aren't for access, they're for creating new files/directories.
$ setfacl -R -m u:gopher:7 data
Now check the data directory again:
$ getfacl data
# file: data
# owner: root
# group: root
user::rwx
user:gopher:rwx
group::r-x
mask::rwx
other::r-x
default:user::rwx
default:user:gopher:rwx
default:group::r-x
default:mask::rwx
default:other::r-x
The only difference we now have a ACL saying that user gopher has rwx access:
user:gopher:rwx
Repeat the experiment
Try writing a data to the directory again:
$ sudo -u gopher touch /tmp/somedir/data/afile
$
It worked!!! Double check the resulting file:
$ ls -l /tmp/somedir/data/afile
-rw-rw-r--+ 1 gopher gopher 0 Oct 7 21:36 /tmp/somedir/data/afile
It doesn't make sense if the unix file permissions disagree to the acl entry and vice versa. Accordingly, the manual page (acl(5)) says what you ask for:
CORRESPONDENCE BETWEEN ACL ENTRIES AND FILE PERMISSION BITS
The permissions defined by ACLs are a superset of the permissions specified by the file permission bits.
There is a correspondence between the file owner, group, and other permissions and specific ACL entries: the owner permissions correspond
to the permissions of the ACL_USER_OBJ entry. If the ACL has an ACL_MASK entry, the group permissions correspond to the permissions of the ACL_MASK entry. Otherwise, if the ACL has no ACL_MASK entry, the group permissions correspond to the permissions of the ACL_GROUP_OBJ
entry. The other permissions correspond to the permissions of the ACL_OTHER_OBJ entry.
The file owner, group, and other permissions always match the permissions of the corresponding ACL entry. Modification of the file permission bits results in the modification of the associated ACL entries, and modification of these ACL entries results in the modification of the file permission bits.
Addendum in response to the discussion:
What is the reason for coupling ACL mask and file group permissions? What logic does lay behind it?
A good explanation is here. In essence the mask is an
[...] upper bound of the permissions that any entry in the group class will grant.
This upper bound property ensures that POSIX.1 applications that are unaware of ACLs will not suddenly and unexpectedly start to grant additional permissions once ACLs are supported.
In minimal ACLs, the group class permissions are identical to the owning group permissions. In extended ACLs, the group class may contain entries for additional users or groups. This results in a problem: some of these additional entries may contain permissions that are not contained in the owning group entry, so the owning group entry permissions may differ from the group class permissions.
This problem is solved by the virtue of the mask entry. With minimal ACLs, the group class permissions map to the owning group entry permissions. With extended ACLs, the group class permissions map to the mask entry permissions, whereas the owning group entry still defines the owning group permissions. The mapping of the group class permissions is no longer constant.
Best Answer
The default ACL is the ACL that is applied to newly created files in that directory. It is also copied as the default ACL for subdirectories created under that directory, so unless you do something to override it it applied recursively.
The default ACL has no effect on the directory itself, or on any files that exist when you change the default ACL.
So in your situation you need to both set the ACL on the directory (for the directory itself) and set the default ACL (for files that you will create in the directory).