If system temp directory isn't writable, views_plugin_display directory is never created

for any noobs like me out there:
check Site Configuration > File System (mysite.com/admin/settings/file-system) before you do anything else with this issue...
Temp directory field will be red if it's not writable.

:)

Many thanks for the bug report and patch.

Fixed in CVS - http://drupal.org/cvs?commit=455568

I am having this problem in the 7.x branch. Was this patch ported?

This is my error: Could not create temporary directory for result export (temporary://views_plugin_display). Check permissions. [Export Aborted]

My file system is writeable.

Thanks!

Same here for D7 and this issue, except my export did work despite the message

Same issue for me on D7

Same issue for me on D7

So the only way I can reproduce this is when the temp directory isn't writeable. Can you check your settings here: /admin/config/media/file-system

"The file permissions could not be set on temporary://views_plugin_display ..."

Module created the directory 'views_plugin_display' in your temporary:// location as system user 'apache'
Drush executes your view and has apparently no write permissions to the directory as is a different system user.

To fix this, execute a similar script as below to have Drush write permissions

<?php
chmod('/tmp/views_plugin_display', 0777);
?>

(Wrong issue queue)

I have also run into this problem with having multiple distinct sites on the same server. Each site wants to create and own the /tmp/views_plugin_display folder.

A fix is to "chmod 777 /tmp/views_plugin_display" the directory, which will let other sites access it as well.

However, a better solution may be to have the module not use a subdirectory at all and just use unique filenames (/tmp/views_plugin_display_*) in the /tmp/directory.

Alternatively, the program should check for if the directory exists AND IS WRITABLE, not just that it exists.

I've got the same problem on BOA / Aegir / Omega8.cc

Since my temp directory is located within private file system path, I got this same issue on BOA/Aegir.

Just deleted this 'views_plugin_display' directory inside temp directory, create new 'views_plugin_display' directory with 777 and problem goes away.

Regarding #17: This works in BOA and Aegir Vanilla until you migrate or clone the site. Then you have to delete the folder again or re-set the owner to the web server.

For what it's worth this is what I've found specifically with Aegir: I think the issue is that when the module creates the folder it's owned by the web server (in my case www-data), then when Aegir moves the site, or does anything to it, it ensures the owner of the temp files and folders are the user and group aegir (instead of www-data) but the mode of the folder is still 775. For some reason the module throws an error thinking it can't write to the folder because it doesn't belong to the web server. In the end it some how figures out how to write to the temp folder and exports the file anyway, in the end it still throws a big red error anyway.

If I change line 691 of views_data_export_plugin_display_export.inc to the following:

$dir = variable_get('views_data_export_directory', 'temporary://');

And then comment out lines 692 to 696 then run the export again I still get my file but no error messages.

So my question to anyone who knows this module better than me: Is creating a sub folder in the temp folder for the export necessary?

From what I can tell, the issue is compounded on a server where there are multiple Drupal installs, sharing the same global /tmp directory and the server is configured to use suEXEC to grant access to the respective user, instead of using the global apache or nobody user. This setup is usually the default on many shared hosting platforms.

If one person creates the directory in /tmp, any additional users (sites using Drupal with views) are denied access to create the directory because it already exists from the original user.

Really what needs to happen, is that the plugin cache folder needs to have a token string appended to the end to allow any user to create a unique directory instead of the currently defined and generic directory of /tmp/views_plugin_display.

For example:
Site 1: views_plugin_display_bm8b20
Site 2: views_plugin_display_7b6dtw
Site 3: views_plugin_display_l1hs95

I would suggest appending the site domain to the folder, however this kind of defeats privacy on a shared server. Some servers allow access into the /tmp folder and also allow downloading files within that folder... not very secure.

Ideally, for these types of environments, I personally recommend moving the /tmp folder to the root of the home directory for privacy reasons. The only problem with this is that the /home/user/tmp folder won't be automatically cleaned out.

Moving the folder in Home » Administration » Configuration » Media » Settings from /tmp to /home/user/tmp (or whatever your home directory is) does seem to mitigate the error reported on the status report page.

Solve one problem only to create a new one.

I honestly wish D7 would have had a "cache library" module created to handle all file aspects of Drupal caching. I love how boost creates a /public_html/cache folder and dumps everything inside there, instead of putting stuff in the /files directory. To me, /files should be reserved for content related files, not temporary or cache files. Just my opinion. Hope D8 is different.

Update: Just saw @diamondsea post... he basically said the same thing I did, in half the words... that's what I get for skimming, posting, then actually going back to read what was said.

I agree with the need for a unique token in the foldername since the 0777 fix is harder to apply on cloud-based solutions like Acquia where multiple web nodes are created/removed dynamically.