Why can't Boost write to folder with permissions set to 777?

You do it recursively from the cache folder? Do you have php is a super paranoid mode where it won't write to the file system?

Thank you for the reply to his problem above. I have the same problem. And I have two questions.

It seems an unacceptable security risk, IMHO, to chmod 777 any directory except as a diagnostic test for a few minutes. That's the only way I used it. Even so, it did not allow boost to write.

1) What would be the php settings to look for in the output of info.php, to determine if php was in a mode which did not allow it to write to the cache file?

2) It seems that his problem above (possibly mine too) is a chown issue. Which of the three-- "apache", "admin" or "root" -- shoiuld be designated as the owner of the folders and files in the cache file path?

Thanks a million for offering help in here.

A CLUE?
fwiw, I also get a series of five error msgs similar to this:

warning: file_put_contents(cache/perm/www.mysite.net/.boost) [function.file-put-contents]: failed to open stream: Permission denied in /home/admin/mysite/sites/all/modules/boost/boost.install on line 80.

Also, I wanted to get your opinion on 775 permissions, rather than 777.

775 should give the same broad permissions as 777 except to random users, right? I understand this in a general sense. But I am not sure about it as it may apply to boost.

You have safe mode enabled on your server. To fix this issue, you can CHOWN the directory to be the same as PHP/Apache or try deleting the cache directory and let PHP create it.

In terms of 777 vs 775 it depends on your servers setup. If its properly configured then 775 should be all you need. Sometimes 775 doesn't work though so you have to use 777. If you have random users logged in your your server (via SSH) then you have some major issues.

strange... it can create directories but it can't create a file. Is your sites/all/files directory writable; does it work correctly?

Your server might prevent boost from creating files that start with a period. Other then that I can't think of anything else...

marking as fixed. reopen if issue is still affecting you.

Let me sound REALLY stupid, but how do I set up the file cache/perm/zerodouble.com. Do I have to go to my server root and set up a directory called Cache, then put a directory called Perm in it and then put that website in it?

create a directory called cache that is writable by apache/php and boost will do the rest

I switched to VPS recently and started getting same errors, hope i will resolve this soon and post what to do step by step...

p.s.
safe mode isn't on my php, but message i get is

Boost Can not write to file-system
Directory /srv/www/mysite.me/public_html/cache credentials - Permissions: 0755. Owner 1000. Group 1000.
Your credentials - Group ID: 1000. User ID: 1000. Current script owner: setup.

Works when 777 is on, when 755 i get above problem. I dont know how to set apache/php to be able to use cache dir as i am new to linux, if someone knows please write an example.

I had the same errors.

I've changed my permission setting and fixed this problem.

cache (folder) to 777
.boost (file) to 766

running drupal 7.9
i was about to go mad with this problem. i dont know where to check the php paranoid mode, was looking throu my php and did not find it there. i was chown chgrp etc etc with root and username and was changing ny user homedir and chmod 777 many times but got 644 created for new files.
tried latest dev release from october 2011
i changed _ in the prefix to empty space - same thing with front page
finally i changed the _ in the prefix to 1 and its working now

but still i wonder where do i have the protection for files starting with bottom slash or maybe _.
i have nginx+apache2 as backend and redirect from nginx to apache2 also when nginx thrown to errors 4xx 5xx etc

[root@newone.org]cd /path_to_drupal_installation
[root@newone.org]find . -type d -name cache -exec chmod ug=rwx,o= '{}' \;
[root@newone.org]find . -name cache -type d -exec find '{}' -type f \; | while read FILE; do chmod ug=rw,o= "$FILE"; done
[root@newone.org]find . -name cache -type d -exec find '{}' -type d \; | while read DIR; do chmod ug=rwx,o= "$DIR"; done

In my case I need to change the owner and group of the cache directory to apache.apache (the user that apache run under)

I was getting this issue with all directory permissions set to 775 and cache/.boost set to 644 during a server migration from RHEL to CentOS. The Plesk panel owned the cache directory (psacln) so all that was needed was a recursive chown call from the Drupal root directory to assign the owner as apache apache:

[root@domain ~]# ll cache
drwxrwxr-x 453 domain psacln 20480 Jun  1 17:58 normal
drwxrwxr-x 446 domain psacln 20480 Jun  1 17:51 perm
[root@domain ~]# chown -R apache:apache cache
[root@domain ~]# ll cache
drwxrwxr-x 453 apache apache 20480 Jun  1 17:58 normal
drwxrwxr-x 447 apache apache 20480 Jun  4 12:15 perm

I just had this same issue - though /cache was set to 777, Boost still couldn't write to it (at least according to status report).
I changed ownership to www-data (I'm on Ubuntu, and that's what the server runs as) and that cleared everything up.

chown -R www-data:www-data cache
chmod -R 766 cache

And all is well.

Is suhosin somehow involved here?

@Philip_Clarke - thanks for that - very helpful.
I'm on a VPS, and in the process of debugging (and I use the term loosely - in my case it in fact means "staring at the screen for a very long time") I added www-data to the users group, but that didn't help. Perhaps I should go undo that...
Anyway many thanks for your insight.

You need to check what user is apache run under from apache config file and since you are on a vps its better to install suPHP or rusuid module for apache, its not that hard to install those, depending on what flavour is your linux (ubuntu, centos etc etc).

If you can afford a bit more expensive server, get a managed vps like getcadre.com, they'll set the varnish, apache, php, mysql etc etc for you.

same problem on vps drupal 6 fix for this please