Unable to create directory <dir> Is its parent directory writable by the server?

[Brian-Menzel]

I'm getting this error when trying to upload images. I had this plug in working once on a linux ec2 instance, when working on something else I nuked the instance and rebuilt a new one and cannot get this error to go away.

s3-uploads verify completes, i can also do a s3-uploads ls and get a list of all media on my s3 bucket.

I have tried giving my ec2 roll all possible permissions for an s3 bucket, and it seems like i can use the plug in via command line when i ssh into the instance, but the wp-admin portal just won't work at all.

How can I trouble shoot this? I'm at my wits end

EDIT: the full error message from the media console is

"Unable to create directory uploads/2020/06. Is its parent directory writable by the server?"

[joehoyle]

This sounds like S3 Uploads is not actually activated / enabled. Can you confirm that URLs in the Media / Attachments page for existing attachments are pointing to S3?

[Brian-Menzel]

Yes, The images that were already uploaded via s3-uploads when inspected are coming from the cloudfront url, and my s3 bucket. I've also double checked that the plug in is active both via command line and the wp-admin console.

[Brian-Menzel]

If no one has an answer, would anyone be able to point me to where i could begin to debug this? There's nothing in the logs inside of the Log folder that indicate an error, and the only error message I can see ("Unable to create directory uploads/2020/06. Is its parent directory writable by the server?") Isn't getting me anywhere.

[joehoyle]

@Brian-Menzel you could try using wp shell (via WP CLI) to debug this, for example, in the WP Shell, you might want to verify the following:

wp> wp_upload_dir(); // Verify this is outputting `s3://`prefixed paths.
wp> file_put_contents( wp_upload_dir()['basedir'] . '/test.txt', 'test' ); // This should write a test.php file to S3, check for any errors displayed.

[Brian-Menzel]

Ok, I did both of those through the shell, the first one got me this

wp> wp_upload_dir(); => array(6) { ["path"]=> string(34) "s3:// s3 Bucket Snipped/uploads/2020/07" ["url"]=> string(52) "https:// correct URL I Promise. cloudfront.net/uploads/2020/07" ["subdir"]=> string(8) "/2020/07" ["basedir"]=> string(26) "s3:// s3 Bucket Snipped/uploads" ["baseurl"]=> string(44) "https:// correct URL I Promise .cloudfront.net/uploads" ["error"]=> bool(false) }

and the second one correctly uploaded a test.text to my s3 bucket.

the wordpress admin console is still giving the same error though.

"Unable to create directory uploads/2020/07. Is its parent directory writable by the server?"

I have logging enabled in the wp-config.php however i don't see any logs being generated either. it's weird because through command-line the plug in works, it just doesn't work at all through the wp-admin console.

[joehoyle]

Hmm that's odd -- indeed it looks like everything is working as expected on the CLI. Have you tried deactivating all other plugins, to make sure there is no odd conflict going on perhaps?

[rmccue]

Just to check, are you on multisite? If so, did you network-activate the plugin or use mu-plugins? Also, you'll need to use the same site URL with --url via the CLI.

Otherwise, it's possible your php.ini configuration doesn't match between FPM (or whatever's handling the web) and CLI. I can't think of anything off the top of my head there that'd cause this though.

[mdinescu]

I ran into the same issue described here.

I can repro this using the following configuration:

• EC2 instance, running Amazon Linux 2 (amzn2-ami-hvm-2.0.20190313-x86_64-gp2 (ami-061392db613a6357b))
• PHP 7.4 (FPM) + nginx/1.18.0
• WordPress 5.4.2
• Latest S3-Uploads (commit https://github.com/humanmade/S3-Uploads/commit/539d0c16d4fb778caeb4fd2b12f5718fb48baea0)
• The following AWS config (S3 bucket, CloudFormation, IAM role/permissions) https://gist.github.com/mdinescu/e7dc7ba79441d974fdb625fb7afcda05

Note that to replicate the issue you can deploy the stack from the gist above, using the AWS cli

aws cloudformation deploy \
    --template-file s3-uploads-resources.yaml \
    --stack-name test-stack \
    --parameter-overrides DomainName=testapp.com AppShortName=testapp \
    --capabilities CAPABILITY_NAMED_IAM

Then you can spin up an EC2 instance, with the AMI that I indicated, and attach the IAM instance profile created from the CloudFormation stack from above; and then load nginx and php 7.4 on it using the following:

yum update -y
amazon-linux-extras install nginx1
amazon-linux-extras install php7.4
yum install -y php-xml
yum install -y mysql
yum install -y php-mbstring

Then, install the s3-uploads plugin and configure as follows:

define( 'S3_UPLOADS_BUCKET', 'testapp-content' );   // name of s3 bucket (should match name from the stack above)
define( 'S3_UPLOADS_REGION', 'us-west-2' );        // region of the content bucket (set yours accordingly)
define( 'S3_UPLOADS_USE_INSTANCE_PROFILE', true ); // use the IAM instance profile created in the stack
define( 'S3_UPLOADS_HTTP_CACHE_CONTROL', 30 * 24 * 60 * 60 ); // make entries expire in 30 days
define( 'S3_UPLOADS_OBJECT_ACL', 'private' );      // make the uploaded objects private in the bucket (we use cloudfront to serve)
define( 'S3_UPLOADS_BUCKET_URL', 'https://<distributionid>.cloudfront.net'); // put CloudFront distribution here from the stack

[mdinescu]

I've also tested this with PHP 7.2 and nginx 1.12 with same results

And have also tried giving the IAM role broader S3 permissions (ie. "s3:*")

[wunderdojo]

Just ran into the same. The issue is in your php.ini. You need to set allow_url_fopen to enabled:

[Brian-Menzel]

Unfortunately I've tried having the allow_url_fopen both enabled and disabled and it seems to have no real effect

[Brian-Menzel]

Ok, I was wrong, I had set allow_url_fopen to on, but I did NOT restart the php service, restarting the php service set allow_url_fopen to on as set by the php.ini, and now it works!

So, make sure allow_url_fopen is ON and then restart the php service on your ec2 instance.

plug in now works as intended.

[wunderdojo]

Glad it's working. FYI for anyone else who runs into it: If you're running Litespeed restarting that doesn't actually restart php. Just ssh in and do pkill lsphp to get the new settings to take effect.

[dingo-d]

Just to confirm. Make sure your PHP-FPM has allow_url_fopen. It usually works from the CLI because PHP CLI and FPM don't have the same configs, so it can work on the CLI, but not from the admin if the allow_url_fopen is turned off in the PHP-FPM