An addition: my system's default umask is 0027.

on every page view, in the FrontController in init:

            $directoriesToCheck = array(
                    '/tmp/',
                    '/tmp/templates_c/',
                    '/tmp/cache/',
                    '/tmp/assets/'
            );

            Piwik::checkDirectoriesWritableOrDie($directoriesToCheck);

This should have triggered an error asking you to put write permissions on the directory.

The testing code is in Piwik::checkDirectoriesWritable()

Somehow I expect your directories to have is_writable() == true, but still they are not writable by the web server.

Why is that that is_writable returns true in checkDirectoriesWritable? any idea?

Note that if the webserver can't write in tmp/cache/ this is pretty bad for performance, as Tracker will be doing potentially several SQL reads per page view, instead of caching in files the website data.

I'm running PHP as CGI with SuExec. So PHP-scripts are executed as user1 and have full (read+write) permissions, but the webserver-user itself is just in the user1-group and thus can have other permissions to the files than the PHP-scripts.

If php runs with suexec, what is user1's umask?

The umask is 0077 when testing with <? passthru('umask'); ?>.
<? echo decoct(umask()); ?> returns 77 too.

(In [2660]) fixes #1507

I checked out and tested trunk - the files now have sufficient permissions, but the tmp/assets-directory still needs a chmod g+x so that the webserver is able to read files within it.

The problem is, that the permissions that are passed to Piwik_Common:mkdir when creating the directory are masked by the umask too.

When i add

@chmod($path, $mode); // bypass too restrictive umask

directly after the mkdir call in line 311 in Common.php it's working. But I'm not sure if it's a good solution to bypass the umask everytime for all directories...

(In [2669]) refs #1507 - override umask only on public folders

(In [2707]) refs #1507 - add @chmod() here for consistency

Note: we're switching to a php proxy in #1527 -- I'll revert some/all of the previous changes once the new code is commited.

(In [3140]) refs #1507, refs #1527 - revert hack from #1507, and fix unit test on Windows per Julien's email