Getting "files cannot be copied" error when hitting my site for the first time after totally fresh op installation.
I searched for that error and applied all the suggestions that people had, to no avail.
I'm a programmer so I went into file.inc which has the file_copy routine that was bombing. I found the error message and modified it to spit out the $dest field (where it's trying to copy TO) (duh, right?) And it was trying to copy to the sites/default/files/css directory, so I changed the permissions on that as I had already done with the /tmp directory.
hit the site and I got a DIFFERENT "files can't be copied" message and the directory it was trying to copy to was /sites/default/files/js (are you beginning to see a pattern here?) So I deleted and recreated all the directories in files and gave them all a 777 permission. Voilá!
I'm on a shared (re-seller's) system so I am not truly master of my entire domain. I'm kind of like sub-creature of my own directory tree (grrrrr).
Anyway the brute force solution is to figure out what directory it's complaining about not being able to write to and change the permissions so that the system IS able to write to it.
So, if you've tried all the rest (of the solutions offered) and you still have the problem, try the "best" (lol) BRUTE FORCE! woot!
Comments
Like you said, it sounds like
Like you said, it sounds like a permissions problem. And if you're not the system admin, I don't know what to tell you other than contact your host. They might have your virtual directory setup incorrectly. But there's not much you can do if you can't play around with the permissions.
Apache having write
Apache having write permission on sites/default/files (which the two folders you were having an issue with are sub-folders of) is a requirement for installing any Drupal (including OpenPublish). As a matter of fact, Drupal installer should not have let you even begin installation without having access to sites/default/files. I am surprised you got to the errors part.
.............................................
http://twitter.com/inadarei
Apache's write permissions not the problem
Apache's write permissions were not the problem, During the OpenPublish install, I had to change permissions on sites/default/files to 777, like any Drupal install, the problem was when OpenPublish began to create the page, it tried to move things from the /sites/default/files/tmp to the various other directories in sites/default/files (ie: js, css, ctools) but when apache created these directories it created them with permissions of 600 (rw- --- ---) THEN later when it went to move things to those directories, I'm not sure WHAT "user" it thought it was but it couldn't write into the directories that it created. I haven't run across this in my admittedly limited, thus far, drupal experience.
Either it's apache's umask, and I haven't run into it before, or, OpenPublish is setting the permissions with the assumption that this is not a shared system (I'm not sure, but this might be the entire reason why they say it's not supported on a shared system)
All I know for sure was that when I deleted those directories, and recreated them and gave them 777 permissions then it worked fine. I'm wondering, though, by having them wide open like that if I'm not creating a security risk of some kind.
What do you think?
More info on the apache permissions
I just spoke to my webmaster and told him what my "solution" is. He said he could probably "fix" this. What I couldn't get out of him before he had to get off line was whether our setup was a standard drupal shared installation or not... I'm going to ask him that later. If it is then others will experience this as well. In any event, I will capture what he says and update my posts accordingly. Thanks for the input. If he does something not documented and it's a legitimate "fix" of some sort, I'll post it.
Thanks irakli
It's the .htaccess within the tmp filder
For thos who like to know after searching high and low, deleting folders, chmod, even new install: in the end it was the .htaccess file within the tmp directory with the wrong ownership. I set ownership to apache and the error disappeared.