on the aegir master ~platform/$p/..sites/files are filled with real site data ( overwriting permission on remote during migrate)

I also have looked at http://drupal.org/node/994210

I think a general solution here would be:
- do not change the permissions on folders aegier does _not know about_. Only change those things for files/tmp and every known one
- Do change the ownership of files/* -R to aegir:www-data
- preserve those permissions while using rsync (archive option)

That means just dont change anything to all those things when verify / migrate / clone happens. Currently, as stated above, files/* is change recursivly, without any "whitelist".

That would solve the issue above and a lot other issues. The admin of aegir has to care about those things once he newly imports a site, chaning the permissions of this contrib modules to correct values or let those contrib modules care about this.

As www-data cant write to those files / folder later you can even use contrib code to change those permissions back. So its a deadlock and pretty critical

Investigating a bit, it should all come down to

http://git.aegirproject.org/?p=provision.git;a=blob;f=platform/provision...

Which is the only place in the whole code where chmod "could" be called recursivly ( _chmod_recusive is never called directly ). So this kind of comes down to the recursive blacklist

http://git.aegirproject.org/?p=provision.git;a=blob;f=platform/provision...

Debugging it:
running R on sites/intranet.drupal-wiki.com/themes
running R on sites/intranet.drupal-wiki.com/modules
running R on sites/intranet.drupal-wiki.com/libraries

only those 3 folders are exectuted with chmod(x,x,TRUE), so recursivly. sites/XXXX/files is not. That still leaves the question open, what resets the file-permissions in the files/* folder .. must be the same call which changes the group to www-data.

Because

http://git.aegirproject.org/?p=provision.git;a=blob;f=platform/provision...

Is never exectuted recursivly on site/XXX/files .. so my files should have been aegir:aegir after verify, but they were not. aegir:www-data was the outcome. It seems there is some other code i just miss wihch does that?

placing a return into line 1 of that method proves, that that method is not responsible for the changes. Because files and folders are still changed to g-w

even commenting out all those

//    drush_set_option('packages', _scrub_object(provision_drupal_system_map()), 'site');
    // This is the actual drupal provisioning requirements. 
//    _provision_drupal_create_directories();
//    _provision_drupal_maintain_aliases();
    // Requires at least the database settings to complete.
//   _provision_drupal_create_settings_file();

results in a g-w. Iam really confused right now.

just for the records, iam running /var/www/drush/drush.php @XXXX provision-verify directly on the console for debuggin purposes.

After some more digging with debug and commenting out stuff i finally found the responsible code. I was looking for some rsync which actually does it, and it finally was one:

http://git.aegirproject.org/?p=provision.git;a=blob;f=platform/provision...

That code is responsible for resetting the g-w permissions in sites/XXX/files/*

How great is that :( After all of this debuggin you finally face the fact, that the issue was infront of the screen...

While i was fiddling arround with the bug in beta2, that files got lost on migration, i was trying to rsync the files to the master into the platform there ( which is a stupid idea ). Well now, those files where synced and had this permmissions, so thats why that rsync "was responsible", or rather it was me fiddling to much finding that issue and forgetting to remove those folders again.

@mig5: really nice attitude.

Well it seems to be different as suggested @ #8

I just deployed(imported) a site by:
- createing the site, deploying it on the server
- reimport the database, cp -fr files from the old
- then i migrated the site several times

Suddenly i recognised that my permissions ( g+w ) are not preserved anymore as described above. I directly check the aegir server if files are again under (aegir master, not remote!) ~/platforms/$platform/...files/ and yes, they are. All files, not only the basic directories can be found there. They have the permissions g=r and are always synced back.

So finally, i was wrong that i actually manually copied the file on the aegir master, actually they are copied by aegir in some of its processes. As later on, see above, an rsync on files/ is run, all those files an permissions are again copied on the remote, overwriting :
- anything existing ( holy shit .. ) ... i hope that is covered by the rsync protocol "do not overwrite anything newer then you"
- all the permissions resetted

So the bug is:
Why are the files in ~/platforms/$platform/...files/ at all? I dont think this is by design, even by the spoke model. Any ideas?

changing title

Well i reproduced it:

1. create a site on platform A on a remote
2. create some files on that file or use 'touch foo' whatever
3. reverify the site ( anything is fine, files are not synced back to the master)
4. AEGIRMASTER:platforma/sites/yoursite/files/ should be just fine, files are not here
5. create a new platformB
6. migrate the site from platformA to platformB
7. AEGIRMASTER:platformB/sites/yoursite/files should now include all files which have been on the sites after step 2

After 7, those files are "rsynced" on every migration, eventhough they could have been deleted on the remote site already. The other issue is the permission issue mentioned above

- backup copies files
- to be able to put files back on the remote

Pretty funny if your site has 5-10GB files.

reopen issue on interest, iam solving this for myself.