xmlsitemap cache directory created with incorrect permissions using aegir

same problem here, but I think this is problem of aegir, not the sitemap module....

anything new?

Aegir problem or xmlsitemap's ?

not sure. dir is created thorugh file_prepare_directory with these flags: FILE_CREATE_DIRECTORY | FILE_MODIFY_PERMISSIONS

maybe aegir should check permission in files directories every 10 cron runs.

set user to aegir:www-data for files -R
and check permissions.

Fix typos (auto-spell correction aegis -> aegir)

Please try again with Aegir 2.x, as Aegir 1.x is deprecated. If it remains an issue, please post the results here, and we'll take another look.

I am experiencing this issue with Aegir 2.x, using a custom installation profile that includes and depends on XML Sitemap. Attached is a screenshot of my Status report page after a new site is installed via Aegir.

The file mentioned in my Status report page appears to have the wrong group - "aegir" instead of "www-data", which means Apache is unable to modify it.

Here is what an "ls -al" gives me in the directory. Notice that the group of the file is "aegir", not "www-data".

drwxrwxr-x  2 aegir aegir    4096 Apr  8 16:40 NXhscRe0440PFpI5dSznEVgmauL25KojD7u4e9aZwOM

Using Aegir 2.1

The folder (public://xmlsitemap) ownership is www-data:www-data and the cache file directory ownership is aegir:aegir. And then the actually sitemap file is aegir:aegir.

This throws a warning in the status report saying

The following directories were not found or are not writable by the server.
public://xmlsitemap/N56LAdf5476UH78yasd78had87q3hdiuan

I verified the site through aegir's frontend but it didn't change anything, so I manually changed the above directory to aegir:www-data and that removes the warning in the status report.

I have the same problem. No solution yet? My problem is worse because I don't have chown rights.

This is the relevant commit. It introduced the code with which we do not blindly chown recursively.

commit 1da8abb3f592b1f203d4195b9e65eadb63baa8d1
Author: Antoine Beaupré
Date: Fri Dec 10 15:34:35 2010 -0500

do not attempt to chown files/ dir during verification

the rationale here is that we're not running as root, and therefore
chown is likely to fail, unless the file already has the right owner,
in which case a chown is not necessary.

To quote chown(2):

Only a privileged process (Linux: one with the CAP_CHOWN
capability) may change the owner of a file. The owner of a
file may change the group of the file to any group of which
that owner is a member. A privileged process (Linux: with
CAP_CHOWN) may change the group arbitrarily.

So this was just a cause of trouble without any possible benefit
unless we run with capabilities, and we shouldn't assume this (right
now?).

Via an implementation of provision_drupal_chgrp_directories_alter() you could probably add the xmlsitemap path.

Marking as closed as due to a lack of activity.
--
This is a templated response, please re-open or comment if you think it's in error.