Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 UTC on 18 March 2024, to get $100 off your ticket.
I recently installed the CTools module, is working fine, but getting this error in the status report:
CTools CSS Cache Unable to create
The CTools CSS cache directory, ctools/css could not be created due to a misconfigured files directory. Please ensure that the files directory is correctly configured and that the webserver has permission to create directories.
Is there a way to correct this? I am running Linux 11.04 and using drupal 7.7.
Thanks in advance.
Comments
Comment #1
sigkg CreditAttribution: sigkg commentedWith that issue would it prevent Panels and Views not to work properly?
Thanks in advance.
Comment #2
merlinofchaos CreditAttribution: merlinofchaos commentedIt would cause several things to not work probably, particularly embedding CSS and things like flexible layout.
I can't tell you how to fix it, because the problem is that the webserver does not have permission to create the directory. You need to make sure that the files directory is writable by the webserver, and doing that varies from setup to setup.
Comment #3
sigkg CreditAttribution: sigkg commentedThanks for your help.
Comment #4
rainbow1119 CreditAttribution: rainbow1119 commentedthe directory refer to sites/default/files/ctools, not the sites/all/modules/ctools. chmod 777 sites/default/files/ctools
Comment #5
camilo.escobar CreditAttribution: camilo.escobar commentedWhen a site is moved, for example using a .tar.gz file and you extract the content in the new server, be sure the folders and files into the sites/default/files folder belong to the user "nobody" and the group "nobody". It occurs that when you extract the content from a .tar.gz file the user is switched to your current user. Just use the chown and chgrp comands to change them. Go to sites/default and write:
chown -R nobody files/*
chgrp -R nobody files/*
Comment #6
pmkanse CreditAttribution: pmkanse commentedCheck your file system path
if its like "sites/default/files"
go to files directory and give 777 permission to files/ctools
run CRON check status report.
If error still exist just create files/ctools/css and give permission 777
CHEERS!!!
Comment #7
Orange CreditAttribution: Orange commentedI did all of that:
1. go to files directory and give 777 permission to files/ctools
2. run CRON check status report.
3. If error still exist just create files/ctools/css and give permission 777
And I still get this when I run update.php:
PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'orangepa_opforum7.ctools_css_cache' doesn't exist: DELETE FROM {ctools_css_cache} ; Array ( ) in ctools_css_flush_caches() (line 572 of /home3/orangepa/public_html/drupal-7.19/sites/all/modules/ctools/includes/css.inc).
Now, when I check
~/public_html/forum/sites/default/files/ctools
something has removed the css subdirectory.
Again and again, update.php removes css. ??
I put it back, and the script deletes it again, so I get the same error message as above.
Help??
Comment #8
merlinofchaos CreditAttribution: merlinofchaos commentedOrange: You're conflating two issues. This issue is about creation of a file in the files directory. The error you're seeing, however, is about the creation of a table in the database. It indicates that somehow CTools did not install correctly. This seems to happen in rare occasions, and as near as I can tell is a bug in the core install code, but I've never been able to duplicate it, nor do I have any idea what's going on when it happens.
I recommend disabling the CTools module (this means disabling a lot of modules that require it), uninstalling it, and then reinstalling it. The devel module has a 'reinstall module' UI that will make this drastically easier, and I highly recommend giving that a try.
That should ensure that the CTools cache table is created correctly.
Comment #9
Orange CreditAttribution: Orange commentedOkay, thank you. I'll try that.
Comment #10
Orange CreditAttribution: Orange commentedOkay, I tried it, and Ctools refuses to uninstall. I've disabled everything related to it like panel and views, and even uninstalled that stuff, but Ctools does not appear on the uninstall menu. I've double-checked that everything related to it is disabled, and so is all of it.
??
I've also installed the devel module, but don't see any reinstall function.
Comment #11
Orange CreditAttribution: Orange commentedOkay, I seem to have worked my way around it:
mkdir ~/xx
cd ~/public_html/forum/sites/all/modules
mv ctools ~/xx
then reinstall ctools
... and it does it without grumbling that ctools is already installed.
and then apparently, I can forget about the backup copy of ctools in ~/xx
That has eliminated the error message.
Comment #12
videographics CreditAttribution: videographics commentedThis remains a problem. This error message appears even when ctools is able to consistently create and write to the ctools/css directory. While this message may show up when there are actual problems with directory permissions, testing strongly suggests ctools is still falsely reporting this error in certain situations.
How ctools gets 'confused' is a mystery, but I can easily reproduce a change in the reporting on my system: After reinstalling ctools using the Devel module's 'Reinstall modules' function, the Status report shows "CTools CSS Cache Exists" instead of the error, but only for the first time the Status report is run after reinstalling. I see the same behavior after logging out, clearing all caches using drush, and logging back in. In both cases, the error is gone the first time Status report is run and then all subsequent Status reports show the error.
I'm not experiencing any functional problems with ctools, ctools is actually able to create and write to the directories, and my directory permissions are not spontaneously changing after every login or ctools reinstall. This all strongly suggests this is a ctools reporting problem.
At the very least this error reporting shouldn't be changing just because the user is reloading the Status report page.
Comment #13
DamienMcKenna@videographics: I've found that if the public files path is configured to use a symlink you end up seeing errors even though the files are saved, the same problem problem occurs in Backup Migrate (#1337766: File permissions) and probably others.
Comment #15
karolus CreditAttribution: karolus commentedI'm experiencing the same problem on my dev site, but not locally.
To add to the issue: the sites/default/files/ctools and sites/default/files/ctools/css folders have permissions applied to them that don't allow me to delete them or even change permissions. All other functionality on the site appears to be OK.
As videographics suggested in comment 13, is this a reporting problem in cTools?
I'd also add that this issue appeared to have occurred after using Drush rsync to push files from local to dev. According to server support technicians, it has to do with permissions being set to nobody because of the automated process.
Comment #16
karolus CreditAttribution: karolus commentedApparent file permissions issue with cTools CSS cache in the sites/default/files folder
Comment #17
ryan.gibson CreditAttribution: ryan.gibson commentedSeems to be an issue for me as well after migrating sites. Changing permissions on directories for ctools or css isn't resolving it.
Comment #18
videographics CreditAttribution: videographics as a volunteer commented(Please ignore. Accidentally posted a comment intended for a different thread.)
Comment #19
saimonn007 CreditAttribution: saimonn007 as a volunteer commentedI had the same problem with CTOOLS - in my case in ftp client I couldn't make a folder. And I started to search the answer. And the problem was that I used 112 % of my capacity at server so the drupal couldn't make any move.
Comment #20
mikestratton CreditAttribution: mikestratton commentedThe problem still exists. I ran into this after migration.
Comment #21
mikestratton CreditAttribution: mikestratton commentedHere is the fix:
Change the directory permissions on the ctools directory located in /public_html/sites/default/files.
Changing the directory permissions in /public_html/sites/all/modules will not resolve this.
In terminal:
cd sites/default/files
sudo chmod 777 ctools
Comment #22
mikestratton CreditAttribution: mikestratton commented777 permissions is a security risk. You can alleviate this by changing ownership to www-data
cd sites/default/files
sudo chown www-data: ctools
sudo chmod 755 ctools
Comment #23
karolus CreditAttribution: karolus commentedThere is another possible way this folder permissions issue can manifest itself--if your Web server uses PHP-CGI wrap (and/or Fast CGI). In this case, you may not be able to set any permissions for the folders themselves (due to server security), but need to be sure your settings in your cgi-bin files and .htaccess are correct. If not, there may be a lot of frustration over an issue that can be easily solved.
Comment #24
ikkehr CreditAttribution: ikkehr commented#21 worked for me
Thanks @mikestratton!
Comment #25
ikkehr CreditAttribution: ikkehr commented#21 worked for me
Thanks @mikestratton
Comment #26
JohnFF CreditAttribution: JohnFF as a volunteer commentedDon't ever, ever,
ever
set a file in your webroot to be 777. Everyone who did recommended this should be ashamed, and put you and others at risk
Configure the file so that either the owner or the web root can write to it. I use 750 where the owner is www-data, or 770 where the owner is not www-data but the owner is a member of the group www-data.
Comment #27
mikeytown2 CreditAttribution: mikeytown2 commentedSomething tangentially related that I recently ran across. file_unmanaged_save_data() will randomly return FALSE on our filesystem, producing errors like this
This error is not reproducible do to it being caused by a race condition. The string for that watchdog message is inside of file_unmanaged_copy().
This results in a data structure like this being added to the drupal_add_css array
When in reality it should look like this
My guess is that the root cause of this issue is #2752783: [D7] file_unmanaged_move() should issue rename() where possible instead of copy() & unlink().
Checking the return value of ctools_css_cache() would be a good starting point. It always assumes it will be a string but it can sometimes be FALSE. A robust workaround for this core issue is found in here advagg_save_data()
Comment #28
cdmo CreditAttribution: cdmo commentedThanks mikeytown2. One of the sites I manage has been hitting this problem every time I deploy new code (updates to custom modules/themes, reverting features, clear cache...). Ctools kept hitting this error of not being able to copy the generated css into place despite proper file permissions. Installed
advagg
and styles reappeared.Comment #29
allexim CreditAttribution: allexim as a volunteer commentedThe matter with virtual private servers is
to set the proper owner and the group...
it depends, which control panel you use
in my case, having deal with ispconfig -
websites have them own ID and Client
hence, correct way should be: chown -R web{number}:client{number} {web_folder_path}
and, if required, to modify permissions: chown -R 755 {web_folder_path}
As opposed to given 777 permissions - definitely, it makes the website an entirely vulnerable
Comment #30
apadernoComment #31
baugabri CreditAttribution: baugabri as a volunteer commentedHi every body, In my case was that my hosting disk was full, so I increase disk space and the problem was solved.