How to resolve the WordPress BackWPup plugin's `is_readable(): open_basedir restriction in effect. AWS path warning`?

When I opened it as usualWordPress backendI'm going to take a look at the backup logs.

Then, I saw a bunch of yellow ones.

Warning, warning, and more warning.

警告: is_readable(): open_basedir restriction in effect. 
File(/home/admin/.aws/config) is not within the allowed path(s): (...)

The backup did complete without interruption, but the status bar was completely yellow, which was really annoying to look at.

Do you know that feeling? It's like you submit a PR, all the CIs are green but there's a lint warning. You know it won't affect the operation, but you still feel uncomfortable.

I thought about it for a moment.

Can this problem be completely solved?

The real reason for the BackWPup warning: The AWS SDK triggered the open_basedir limit.

Honestly, at first I thought it was a problem with the backup plugin BackWPup, since the warning popped up in its logs.

But upon closer inspection, something was wrong.

The warning mentioned a path./home/admin/.aws/configThis is the AWS SDK automatically looking for the current user's default AWS configuration directory during initialization.

That sounds a bit convoluted, right?

Essentially, this means that if you install an AWS-related plugin in WordPress, such as S3 storage or CloudFront, these plugins all use the AWS SDK at their core. When the AWS SDK starts, it will automatically check your home directory for AWS SDK installation tools..awsThis folder contains configuration files and credentials.

However, for security reasons, the PHP server opened a...open_basedirThis thing is basically like marking out a territory on the server and telling PHP that you can only move within this territory and not wander around.

/tmpThe directory is in the whitelist, the website directory is in the whitelist, but your directory, sorry, is not.

When the AWS SDK tries to access your directory, it gets blocked.

Then the warning popped up.

The correct approach to resolving open_basedir warnings: Redirect the AWS configuration path.

To be honest, my first reaction was to change it.open_basedirConfigure, put/home/adminAdd it in.

But then I thought about it again, and realized that wasn't right.

You made a mistake with this. The formatting is wrong. You missed a forward slash and added an extra space. It resulted in a 500 error, and the entire site is gone.

Andopen_basedirIt was opened for security reasons. If you open it up, you're essentially giving the server a loophole, which isn't worth it.

Is there a safer way?

I thought about it for a moment, since the AWS SDK is what you need to find.../home/admin/.aws/configCan I trick it into looking for this file somewhere else?

Go to one of the places that are already on the whitelist.

Fix WordPress BackWPup warnings: Add two lines of code to wp-config.php

The solution is actually ridiculously simple.

In WordPresswp-config.phpJust add two lines of code to the file.

// 修复 BackWPup / AWS SDK open_basedir 警告
putenv('AWS_CONFIG_FILE=/tmp/aws_config');
putenv('AWS_SHARED_CREDENTIALS_FILE=/tmp/aws_credentials');

加在/* That's all, stop editing! Happy publishing. */Just go above this line.

Just these two lines.

Gone.

Detailed Explanation of the Principle of Putenv Redirecting AWS Configuration Paths

Think about it, what these two lines of code are essentially telling the AWS SDK, "Don't go through my directories, go to..."/tmpLocate the configuration file in the directory.

/tmpThe directory, almost all servers are inopen_basedirIt's in the whitelist because it's originally the system's temporary directory.

Looking at the AWS SDK, oh, the configuration file is in.../tmpThen go/tmpFind it. It perfectly bypasses security restrictions and doesn't affect anything.

And you don't actually need to go./tmpWhat to create in the directoryaws_configThe files. Because you most likely haven't used AWS configuration files at all, those configurations are all empty default values. (AWS SDK...)/tmpAfter searching around, I found nothing, so I'll just use the default configuration; it won't make any difference.

This is like lying to your cat, saying the cat food is in the next room. The cat runs over, finds nothing, and comes back, and nothing happens.

Verification of repair effect: BackWPup backup logs have returned to normal.

After making the changes, go back to the WordPress backend, open BackWPup, and click "Run Now".

Check the logs after the run is complete.

The bright yellow warnings are gone, replaced by green "successfully completed" messages.

It's so smooth.

Two lines of code, zero risk, less than 10 seconds to modify, and the problem was completely solved.

These kinds of "not fatal but annoying" problems are actually the most energy-consuming. Because you don't know if it will suddenly become worse after an update, and you don't know if it will affect other plugins.

If something can be completely eliminated with two lines of code, then don't leave it in the way.

Okay, that's all for this article.

Because this matter is not complicated, I don't need to give you any background knowledge, industry analysis, or future trends.

It's just a small warning in the WordPress admin panel, and a fix with two lines of code.

Hopefully, the next time you see that yellow warning, you'll remember this article.