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

sigkg’s picture

Priority: Normal » Major

With that issue would it prevent Panels and Views not to work properly?

Thanks in advance.

merlinofchaos’s picture

Status: Active » Closed (works as designed)

It 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.

sigkg’s picture

Status: Closed (works as designed) » Closed (fixed)

Thanks for your help.

rainbow1119’s picture

the directory refer to sites/default/files/ctools, not the sites/all/modules/ctools. chmod 777 sites/default/files/ctools

camilo.escobar’s picture

When 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/*

pmkanse’s picture

Check 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!!!

Orange’s picture

I 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??

merlinofchaos’s picture

Orange: 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.

Orange’s picture

Okay, thank you. I'll try that.

Orange’s picture

Okay, 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.

Orange’s picture

Okay, 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.

videographics’s picture

Version: 7.x-1.0-rc1 » 7.x-1.6
Category: Support request » Bug report
Priority: Major » Normal
Issue summary: View changes
Status: Closed (fixed) » Active

This 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.

DamienMcKenna’s picture

Status: Active » Fixed
Related issues: +#1337766: File permissions

@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.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

karolus’s picture

I'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.

karolus’s picture

Status: Closed (fixed) » Needs work
Issue tags: +error, +file permissions

Apparent file permissions issue with cTools CSS cache in the sites/default/files folder

ryan.gibson’s picture

Seems to be an issue for me as well after migrating sites. Changing permissions on directories for ctools or css isn't resolving it.

videographics’s picture

(Please ignore. Accidentally posted a comment intended for a different thread.)

saimonn007’s picture

I 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.

mikestratton’s picture

The problem still exists. I ran into this after migration.

mikestratton’s picture

Here 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

mikestratton’s picture

777 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

karolus’s picture

There 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.

ikkehr’s picture

#21 worked for me
Thanks @mikestratton!

ikkehr’s picture

#21 worked for me
Thanks @mikestratton

JohnFF’s picture

Don'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.

mikeytown2’s picture

Something tangentially related that I recently ran across. file_unmanaged_save_data() will randomly return FALSE on our filesystem, producing errors like this

The specified file temporary://fileP47Mwl could not be copied to public://ctools/css/196d201557aea75aa8c28f125520d2a1.css.

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

[12] => Array (
    [type] => file
    [group] => 0
    [weight] => 0.026
    [every_page] => FALSE
    [media] => all
    [preprocess] => 1
    [data] => sites/all/modules/panels/css/panels.css
    [browsers] => Array (
	    [!IE] => 1
	    [IE] => 1
	)
    [scope] => header
)
[13] => Array (
    [type] => file
    [group] => 0
    [weight] => 0.052
    [every_page] => FALSE
    [media] => all
    [preprocess] => 1
    [data] => FALSE
    [browsers] => Array (
	    [!IE] => 1
	    [IE] => 1
	)
    [scope] => header
)

When in reality it should look like this

[12] => Array (
    [type] => file
    [group] => 0
    [weight] => 0.026
    [every_page] => FALSE
    [media] => all
    [preprocess] => 1
    [data] => sites/all/modules/panels/css/panels.css
    [browsers] => Array (
	    [!IE] => 1
	    [IE] => 1
	)
    [scope] => header
)
[13] => Array (
    [type] => file
    [group] => 0
    [weight] => 0.052
    [every_page] => FALSE
    [media] => all
    [preprocess] => 1
    [data] => public://ctools/css/196d201557aea75aa8c28f125520d2a1.css
    [browsers] => Array (
	    [!IE] => 1
	    [IE] => 1
	)
    [scope] => header
)

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()

cdmo’s picture

Thanks 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.

allexim’s picture

The 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

apaderno’s picture

Version: 7.x-1.6 » 7.x-1.x-dev
Status: Needs work » Active
Issue tags: -error, -file permissions
baugabri’s picture

Hi every body, In my case was that my hosting disk was full, so I increase disk space and the problem was solved.