If realpath(file_directory_temp() . '/views_plugin_display') doesn't exist, tempnam() will use the system temp directory instead of Drupal's temp directory. If that's not writeable, export fails.

Manually creating views_plugin_display inside sites/default/files (my temp directory) fixed the problem.

#1 views_data_export-981188-1.patch1.31 KBtim.plunkett
Members fund testing for the Drupal project. Drupal Association Learn more


tim.plunkett’s picture

This is not the right way to fix this. But it works.

squarecandy’s picture

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.


tim.plunkett’s picture

Oh, I forgot to mention, I do know that this module is less than 24 hours old, and it is awesome. I was trying to be helpful by posting patches, I'm not complaining that the module isn't perfect yet.

Steven Jones’s picture

Status: Needs review » Fixed

Many thanks for the bug report and patch.

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

Status: Fixed » Closed (fixed)

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

hoZt’s picture

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.


bigjim’s picture

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

tim.plunkett’s picture

Version: 6.x-1.0-beta1 » 7.x-3.x-dev
Status: Closed (fixed) » Active


FYI, in #1 I said "This is not the right way to fix this.", and it was committed anyway :)

mrfelton’s picture

Same issue for me on D7

CarbonPig’s picture

Same issue for me on D7

Steven Jones’s picture

Status: Active » Postponed (maintainer needs more info)

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

aoturoa’s picture

"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

chmod('/tmp/views_plugin_display', 0777);

  • Steven Jones committed 2ecd5e3 on 7.x-4.x
    #981188 by tim.plunkett, Steven Jones: Fixed Using system temp directory...
silurius’s picture

Issue summary: View changes

(Wrong issue queue)

diamondsea’s picture

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.

lsolesen’s picture

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

dat deaf drupaler’s picture

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.

jeremyr’s picture

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?

philsward’s picture

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.

emmonsaz’s picture

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.