What is causing Wordpress file empty error on uploads?

I’ve followed a good number of digitalocean tutorials to DIY transfer my Wordpress Multisite content over from AWS. But for the life of me, I can’t seem to figure out why I get the following when I try to upload anything in wordpress… for both media uploads and wordpress import xml: “Sorry, there has been an error. File is empty. Please upload something more substantial. This error could also be caused by uploads being disabled in your php.ini or by post_max_size being defined as smaller than upload_max_filesize in php.ini.”

Very little on how to troubleshoot this is online… most of which is about php.ini max configs, which… yes, post_max_size is large enough as well as upload_max_filesize in my /etc/php5/fpm/php.ini

Here’s my setup (some info irrelevant for this issue but for full picture I’m sharing anyway): Cloudflare (is off) to Floating IP Digitalocean Floating IP to droplet 1 Droplet Ubuntu 14.04 with nginx using php-fpm (we’ll call this droplet 1) Droplet Ubuntu 14.04 with mysql (droplet 2) Droplet Centos 7 x64 with nginx and Jenkins (droplet 3)

Droplet 1 is the wordpress multisite installation droplet Droplet 2 is local network connections only Droplet 3 is to update wordpress installations in droplet 1 from repo service Let’s encrypt used for Droplet 1 & 2 PHP5-fpm pools created for each wordpress ms installation. For now, all installations nginx conf files are deny all except for my testing IPs. Chmod 755 for all directories in each site root Chmod 644 for all files in each site root Chmod 660 for wp-config.php Chown php5-fpm pool users on all files/directories for within each site root eg:

chown -R example1:example1 /usr/share/nginx/example1/*
chown -R example2:example2 /usr/share/nginx/example2/*

although my site root locations are different These php5-fpm users are NOT in www-data group nor sudo group, read doing so is security risk but even so I temporarily tried adding them to www-data group to see if the wordpress uploading would work… it didn’t. I’ve also tried example1:www-data ownership as well, didn’t work. I’ve also tried chmod 777 for uploads folder, didn’t work. error logs have the following:

in php_scripts_error.log (this error is unrelated)

[20-May-2016 04:40:05 UTC] PHP Warning:  php_uname() has been disabled for security reasons in /usr/share/nginx/example1/app/wp-content/plugins/debug-bar/debug-bar.php on line 189

in wpms-error.log (this is what doesn’t make sense to me)

2016/05/20 01:12:00 [crit] 1584#0: *1251 open() "/usr/share/nginx/example1/" failed (13: Permission denied) while logging request, client: [my IP address], server:, request: "POST /wp-admin/admin-ajax.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm-example1.sock", host: "", referrer: ""

in these site’s nginx conf files I have:

access_log  /usr/share/nginx/example1/$host-access.log;

access logs are enabled in nginx.conf (even though not recommended) but access logs for each site is not being written to their site roots. Wordpress is one directory below their nginx conf roots. eg /root/app/wordpress_files_here

so… after trying everything I’ve read online… I’ve yet to find out even what the underlying issue is… because file permissions alone doesn’t seem to be it.

Maybe a combination of issues is causing this?

Show comments

Submit an answer

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

Sign In or Sign Up to Answer

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

This question was answered by @PatrickDO:

Hi @tryhardnotenough,

I believe that all of your logs aren’t being correctly written, or some errors are being hidden from you that’s stopping you from seeing what the problem is. The error in the wpms-error.log, seems to indicate this.

Something you can try is to sudo to the user id, and see if you can create a file in that location with an editor (sudo -u <id> /bin/bash). Let us know how it goes, and we can go from there!

View the original comment