A long time ago, I’ve uploaded a picture of my Purple Leaf Plum during the summer.
Now, after numerous updates and server changes, I tried to access the image only to get thrown a generic PHP error 500.
Further investigation shows that it also happened with quite a few older files as well, including some images from some of my old pages.
Et tu, high-school portfolio?
While I could care less about that breadboard schematic back in 11th grade, that purple leaf plum picture was pretty nice.
Therefore, let’s embark on a journey to recover access to my purple leaf plum from a Windows Server machine running WordPress on IIS.
(or for the impatient, a TL;DR: PHP file uploads weren’t inheriting correct permissions)
- Browsing directly to files uploaded in the past would result in an err. 500.
- Missing images/thumbnails/files.
- Unable to edit (e.g. crop images) through WordPress Media Library.
Mozilla Development Network (MDN)
500 Internal Server Errorserver error response code indicates that the server encountered an unexpected condition that prevented it from fulfilling the request.
Knowing what a 500 means is one thing; pin-pointing the cause is a whole new ballpark altogether, considering 500’s can be pretty vague.
In the past, I’ve modified the permissions for alvinr.ca in such a way that I wouldn’t be able to update through wpadmin – only manually. While this gave some odd behavior through wpadmin (asking for FTP credentials when hitting ‘Update Now’), it was expected.
Could this error 500 issue be related?
Well, let’s take a look at the permissions for one of our uploads.
Well, we’re missing some entries; namely Users, IUSR and IIS_IUSRS.
Unsure how that happened, but let’s add the permissions and try browsing to it again.
For IUSR & IIS_IUSRS:
- Read & execute
For Users (domain\Users):
- Read & execute
Aha! It works! The Purple Leaf plum is now visible in all its glory.
Now that we’ve resolved that, let’s continue on with our lives. Making another post, uploading another image… and guess what.
It happens again.
Same error 500, and the uploaded file is missing those permissions!
What’s going on here?
Who/what keeps nuking necessary permissions to my WordPress uploads?
To better understand this, let’s talk about what exactly happens when you upload a file to WordPress.
The process of uploading a file to WordPress is handled by PHP. During this process, PHP retrieves the file from the client, placing it in a temporary location, before moving it to
wp-content/uploads as dictated by WordPress.
When a file is written to this temporary location by PHP, it inherits permissions associated with that location.
When the file is moved to a WordPress specified location, it’s just that – moved. It STILL retains the permissions from the PHP temporary location.
And since PHP is not ran by a user that owns the file, its permissions cannot be changed after the move.
This explains why new uploads are affected.
It also explains possible origins to this problem;
- Updates to PHP
- Modifications to PHP or your IIS site’s handler mappings
- Modifications to the temporary file upload location written to by PHP
- Define a new temporary file upload location for PHP
- Add specified users above to temporary file upload location used by PHP (not recommended)
Since the default location for PHP file uploads is
C:\Windows\temp , which is used by other applications including the system itself, I’d like to keep its permissions pristine before it causes conflicts, or even worse, opens security holes.
Thus; let’s specify a NEW default temporary file upload location by modifying
php.ini (PHP configuration file).
- Create a new location to be used for temporary file uploads by PHP
- Launch IIS Manager, identify PHP used for site by inspecting Handler Mappings
- Navigate to location of php.ini for PHP installation identified previously
- Open php.ini, find the
upload_tmp_dirconfiguration item, un-comment by removing the leading ‘
;‘, and specify the new location
How to find your PHP configuration (click thumbnails to enlarge image):
1. Select site in IIS Manager > Handler Mappings
2. View Ordered List to determine PHP used by site
3. Sort by path, identify highest priority name for *.php path
4. View Unordered List, and double-click item identified previously
Lessons learned; error 500’s are sometimes more predictable when your web application is WordPress. Also; clean up your handler mappings.
May your posts be fresh, and your images always available.