Permissions in /static/platforms/platform-name/site getting corrupted each morning?

I have had lots of trouble with static platform sites regarding permissions. I do not know if this is a real issue, as perhaps the consequences are not bad at all, or perhaps I am making the same mistake over and over again. In any case, the following happens repeatedly: (I am using stable boa 2.0.5 with no modifications, php modern only. The only unusual config I am using is I am not using o1 as my octopus instance, I am using a different 4 letter 1 number character string all run together - and my understanding is that this fact never causes any problems and works just as well as using o1)

1.) I create a new static platform makefile. Latest drupal core, additional modules and themes are listed, with their placement listed as "". The makefile itself as ownserships and permissions set to 999:100 664, and is located in /data/disk/o1/static/platforms

** to note: the default aegir/octopus o1 insance has the default path listed as /data/disk/o1/static/new-platform-name
and I have to edit it to include the /platforms/ subdirectory that should come after /static/, thus giving:
/data/disk/o1/static/platforms/new-platform-name . My understanding is that this is not an error, and we are expected to always add the subdirectory /platforms/ after the static directory when defining the platform path. Isn't that correct?

2.) I login via ssh as my o1.ftp user and drush dl drupal into the correct place. Then I can verify the new platform - from my o1.server1.main-domain.com octopus instance - and it verifies with no errors.

3.) I create a site on the new platform. It works fine, I can login, run cron, clear caches, etc, start building the site, and from my o1 octopus instance I can flush caches and verify the new site, and there are no errors or warnings.

4) The next day, after the morning barracuda/octopus/aegir run, when I verify the site from my o1 octopus instance, it always returns these exact same errors (the newly created platform verifies again with no errors):

Changed permissions of sites/domain.com/files to 2770
Could not change permissions sites/domain.com/files/tmp to 2770 (chmod to 2770 failed on sites/domain.com/files/tmp)
Could not change permissions sites/domain.com/files/images to 2770 (chmod to 2770 failed on sites/domain.com/files/images)
Could not change permissions sites/domain.com/files/pictures to 2770 (chmod to 2770 failed on sites/domain.com/files/pictures)
Could not change permissions sites/domain.com/files/css to 2770 (chmod to 2770 failed on sites/domain.com/files/css)
Could not change permissions sites/domain.com/files/js to 2770 (chmod to 2770 failed on sites/domain.com/files/js)
Could not change permissions sites/domain.com/files/advagg_css to 2770 (chmod to 2770 failed on sites/domain.com/files/advagg_css)
Could not change permissions sites/domain.com/files/advagg_js to 2770 (chmod to 2770 failed on sites/domain.com/files/advagg_js)
Could not change permissions sites/domain.com/files/ctools to 2770 (chmod to 2770 failed on sites/domain.com/files/ctools)
Created sites/domain.com/files/ctools/css
Changed permissions of sites/domain.com/files/ctools/css to 2770
Could not change permissions sites/domain.com/files/imagecache to 2770 (chmod to 2770 failed on sites/domain.com/files/imagecache)
Could not change permissions sites/domain.com/files/locations to 2770 (chmod to 2770 failed on sites/domain.com/files/locations)
Could not change permissions sites/domain.com/files/xmlsitemap to 2770 (chmod to 2770 failed on sites/domain.com/files/xmlsitemap)
Could not change permissions sites/domain.com/files/deployment to 2770 (chmod to 2770 failed on sites/domain.com/files/deployment)
Changed permissions of sites/domain.com/private to 2770
Could not change permissions sites/domain.com/private/files to 2770 (chmod to 2770 failed on sites/domain.com/private/files)
Could not change permissions sites/domain.com/private/temp to 2770 (chmod to 2770 failed on sites/domain.com/private/temp)
Could not change permissions sites/domain.com/files/styles to 2770 (chmod to 2770 failed on sites/domain.com/files/styles)
Could not change permissions sites/domain.com/private/config to 2770 (chmod to 2770 failed on sites/domain.com/private/config)
Could not change permissions sites/domain.com/private/config/active to 2770 (chmod to 2770 failed on sites/domain.com/private/config/active)
Could not change permissions sites/domain.com/private/config/staging to 2770 (chmod to 2770 failed on sites/domain.com/private/config/staging)

SO, I ask myself, is this a real bug? or am I doing something wrong?

/data/disk/fast1/static/platforms/7c/sites/domain.com/files - this folder is set to 111:33 2770.
/data/disk/fast1/static/platforms/7c/sites/domain.com/private - this folder is also set to 111:33 2770.
Is that OK?

/data/disk/fast1/static/platforms/7c/sites/all - this folder is set 111:100 751. (** When the platform and first site in it are
first created this folder is set to 111:100 755 **)
and
/data/disk/fast1/static/platforms/7c/sites - this folder is set 111:100 751. (** When the platform and first site in it are
first created this folder is set to 111:100 755 **)

the newly created site, new-site.com, at /data/disk/fast1/static/platforms/7c/sites/new-site.com, and
yesterdays created site both have the same permissions - these folders are set to 111:100 755.

When I use my o1.ftp octopus user via ssh and drush to download another module into /sites/all/modules/, I get a drush failure message saying that directory is not writable, (it is set to 111:100 775) and I have to modify it to 775 in order to download a new module to be shared among all sites on the platform. Now this makes me think there is a real bug, or error on my part.

Just wondering if this raises an obvious flag? Or, should the warnings be disregarded?