When I use drush to clear cache (drush cc), a message says 

WD print_pdf: Failed to create directory                             [error]
"public://print_pdf/print_pdf_mpdf/ttfontdata" for print_pdf_mpdf.
WD print_pdf: Failed to create directory                             [error]
"public://print_pdf/print_pdf_mpdf/tmp" for print_pdf_mpdf.

These lines are shown before the clear cache options are shown by drush.
What can this be all about?

Comments

jcnventura’s picture

jcnventura
Primary language English
commented
Status: Active » Postponed (maintainer needs more info)

It also happens to me, and it's a slight annoyance, that I mean to fix one day.

I think it means simply that the user with which you're running drush doesn't have write permissions to create those directories in the Drupal public directories. Those dirs should be created by Drupal itself when it's running as the web server user. If they aren't (log messsages will indicate that), then you need to fix the permissions on the public directory.

João

DeNelo’s picture

DeNelo commented
Status: Postponed (maintainer needs more info) » Closed (won't fix)

Yes, that seemed to work - set write perms on the tmp and ttfontdata folders, and drush no longer complains.
Thanks!
(I set a won't fix status on it, not sure if that's entirely true.)

drupsup’s picture

drupsup commented

hi,

> Those dirs should be created by Drupal itself when it's running as the web server user. If they aren't (log messsages will indicate that), then you need to fix the permissions on the public directory.

what should those perms be?

here,

drush @DEV cc
	WD print_pdf: Failed to create directory "public://print_pdf/print_pdf_dompdf/fonts" for print_pdf_dompdf.[error]

@log,

Nov  3 14:01:23 dev DRUPAL: https://dev.loc|1351976482|print_pdf|127.0.0.1|https://dev.loc/index.php||0||Failed to create directory "public://print_pdf/print_pdf_dompdf/fonts" for print_pdf_dompdf.

cd `@DEV dd`/sites/default/files
ls -ald . .. print_pdf
	drwxrwx---+ 13 wwwrun www 4.0K Sep  5 17:28 ./
	drwxrwx---+  3 wwwrun www 4.0K Aug  8 08:24 ../
	drwxrwx---+  3 wwwrun www 4.0K Sep  5 17:28 print_pdf/

ls -alR print_pdf/
	print_pdf/:
	total 12K
	drwxrwx---+  3 wwwrun www 4.0K Sep  5 17:28 ./
	drwxrwx---+ 13 wwwrun www 4.0K Sep  5 17:28 ../
	drwxrwx---+  3 wwwrun www 4.0K Sep  5 17:28 print_pdf_dompdf/

	print_pdf/print_pdf_dompdf:
	total 12K
	drwxrwx---+ 3 wwwrun www 4.0K Sep  5 17:28 ./
	drwxrwx---+ 3 wwwrun www 4.0K Sep  5 17:28 ../
	drwxrwx---+ 2 wwwrun www 4.0K Sep  5 17:28 fonts/

	print_pdf/print_pdf_dompdf/fonts:
	total 8.0K
	drwxrwx---+ 2 wwwrun www 4.0K Sep  5 17:28 ./
	drwxrwx---+ 3 wwwrun www 4.0K Sep  5 17:28 ../
DeNelo’s picture

DeNelo commented
Status: Closed (won't fix) » Active

I've got:

files# ls -ald . .. print_pdf
drwxr-xr-x 26 apache apache 4096 Sep 17 14:32 .
dr-xr-xr-x  3 apache apache 4096 May 14 11:26 ..
drwxr-xr-x  3 apache apache 4096 Sep 17 11:05 print_pdf

files]# ls -alR print_pdf/
print_pdf/:
total 24
drwxr-xr-x  3 apache apache 4096 Sep 17 11:05 .
drwxr-xr-x 26 apache apache 4096 Sep 17 14:32 ..
drwxr-xr-x  4 apache apache 4096 Oct  2 11:00 print_pdf_mpdf

print_pdf/print_pdf_mpdf:
total 776
drwxr-xr-x 4 apache apache   4096 Oct  2 11:00 .
drwxr-xr-x 3 apache apache   4096 Sep 17 11:05 ..
drwxrwxrwx 2 apache apache   4096 Sep 17 11:05 tmp
drwxrwxrwx 2 apache apache   4096 Sep 17 11:05 ttfontdata
-rw-r--r-- 1 apache apache   2058 Sep 23 17:24 ttfontdatadejavusanscondensedB.cw127.php
[cut similar ones out]

print_pdf/print_pdf_mpdf/tmp:
total 16
drwxrwxrwx 2 apache apache 4096 Sep 17 11:05 .
drwxr-xr-x 4 apache apache 4096 Oct  2 11:00 ..

print_pdf/print_pdf_mpdf/ttfontdata:
total 16
drwxrwxrwx 2 apache apache 4096 Sep 17 11:05 .
drwxr-xr-x 4 apache apache 4096 Oct  2 11:00 ..

Don't know if this is a secure setup - but it works for me.

drupsup’s picture

drupsup commented

even using "your" perms, I can't get this error to go away.

fwiw, my Drupal web user *IS* wwwrun:www, so this shouldn't be an issue even with what I had ...

DeNelo’s picture

DeNelo commented

I would like to help you out, but I'm afraid I'm out of options - other than that I know it has to do with permissions, as stated in #1. I guess it's fiddle-around-time... (again)

jcnventura’s picture

jcnventura
Primary language English
commented
Title: WD print_pdf » Don't try to create temp dirs when running drush
Status: Active » Postponed

@drusup: however, when you're running drush you are NOT your Drupal web user.. And your user is not allowed to create those dirs. Even if it was, they would be owned by the wrong user which could create problems later.. The fix for this is simply to try to check permissions before creating those. This is however completely harmless and not high on my priority list, as it only affects drush users.

drupsup’s picture

drupsup commented

> when you're running drush you are NOT your Drupal web user

That's correct. I'm root ... which makes this

> And your user is not allowed to create those dirs

questionable.

> The fix for this is simply to try to check permissions before creating those

as I said, didn't work for me.

> This is however completely harmless and not high on my priority list, as it only affects drush users.

understood.

for me, i'd rather know that my modules are handling files/folders/perms correctly, so, i'll rm it from production for now.

thanks!

jcnventura’s picture

jcnventura
Primary language English
commented

Just for clarification: the module handles the files/folders permissions correctly, but it assumes the code is to be used by Drupal. Drush does other things, and one of those is the fact that it runs the PHP code as a different user than Drupal normally does.

The fact that your root user is not able to create that directory, but clearly your Drupal user is means that your setup has safeguards in place somehow preventing your root user from doing those operations. The fact that your listings have the ACL bit on, as indicated by the '+' sign at the end of your listing might help in finding out what the problem in your setup is.

However I do acknowledge that there's a problem if it is trying to create those dirs during the cache clean.. Currently the module creates those dirs in hook_init(), and it shouldn't.. Like Drupal core, it should only try to create them before running the 3rd party lib.

modctek’s picture

modctek commented

Any updates on this issue?

jcnventura’s picture

jcnventura
Primary language English
commented
Issue summary: View changes
Status: Postponed » Closed (duplicate)

Fixed in #2103095: Failed to create directory public://print_pdf/print_pdf_tcpdf/cache

SandPond’s picture

SandPond commented

If you attempt to run Drush as "root" you will receive this error (depending on the command used). So switch to the user account that owns the Drupal installation that you are working on by entering the following command (substitute your particular user for "drupal_website_user":
su - drupal_website_user

To switch back to "root" user enter:
exit

It's possible that there is more than one cause of this error?

Anonymous’s picture

Anonymous (not verified) commented

I believe this to be a file permissions issue. I fixed it by setting my local account as owner and the webserver user apache as the group;

sudo chown -R localuser:apache print_pdf/*

replace 'localuser' with your local nix box user account. You might need to change 'apache' if your web server has a different system name.

also you should check and add write permissions for group recursively:

sudo chmod -R g+w print_pdf/*

*note you don't need to use the sudo prefix on the terminal if you login as root and change these permissions. For those of you who are not familiar with it.

SandPond’s picture

SandPond commented

Recursively changing file "ownership" and "permissions" for apache and any local users could be risky or at least unorthodox. I would suggest simply logging in as (or switching to) the proper user (original Drush install user) as detailed in #12 above. Alternatively Drush could be reinstalled while logged in as the user which one wishes to run it under.