Jetpack Backup/Restore Connection Failing On Lightsail

AWS Lightsail provides a quick and easy way to stand up WordPress instances with minimal effort for people with a moderate amount of tech skills. It does come with some challenges, however, that are not well documented online. One of those is Jetpack backup/restore connection failing on Lightsail when using the default Bitnami image and latest version of Jetpack.

Once the WordPress instance is up-and-running and you have your SSL certificates and domain pointers configured, it is often prudent to enhance security and stability by implementing Jetpack. Most of the process goes fairly smoothly, however with the curent Bitnami images running WordPress 6.x there is an issue connecting Jetpack’s backup restoration connectors.

Here is a typical message in Jetpack 11.8.3 when you’ve not setup the server connection.

Making The Connection

When you follow the Enter credentials link it brings you to the Jetpack “cloud dashboard” where you manage the connections to all your sites. It will ask for your host and should indicate AWS is the best-guess.

On the Credentials page it will ask for a connection type. The most secure and often most reliable option is to use SFTP. This is a secure transport which helps reduce potential “lurker” type attacks on the data transfer process during a backup or restore.

You’ll want to chose SSH/SFTP as the credential type, enter your server address, and set the WordPress installation path ( /home/bitnami/stack/wordpress/ for a typical Lightsail installation) , choose use private key, and set the server username to bitnami.

The Private key is the pem file you can download from the Lightsail dashboard via “Manage” on your Lightsail instance. You’ll want to open that text file and copy the entire contents into the Private key box provided.

Jetpack Backup/Restore Connection Failing On Lightsail

With the default setup for Jetpack and Bitnami’s latest single site installation of WordPress this connection does not work. While the server connection works, the helper file Jetpack tries to throw on the site does not end up in the right place. You’ll see a rather generic error message like the one below.

With a little more digging on the server side of things it appears Jetpack is trying to create the file in a temporary directory. It seems to get the process started as there are multiple temp files created when testing the “Review credentials” in the /tmp directory on the server.

We can also see some related images in the Apache error logs at /home/bitnami/apache/logs/error_log that include these messages:

mLPiqvXym5KDLOXZMk8%3D
[Wed Feb 15 14:02:59.534416 2023] [proxy_fcgi:error] [pid 142942:tid 139784743712512] [client 192.0.102.61:29348] AH01071: Got error 'PHP message: PHP Notice:  Unknown: file created in the system's temporary directory in Unknown on line 0', referer: https://lancecleveland.com/?rest_route=%2Fjetpack%2Fv4%2Fbackup-helper-script&_for=jetpack&token=fJJqXO%2AOY%24MUalxLbrxIcEo%24X%212vF4%21%28%3A1%3A0&timestamp=1676469779&nonce=IMsxSOx370&body-hash=os%2FWNGET3dWFpzwlmkN9cn5%2F8so%3D&signature=muX7CrhMPLiyw8CWtxTf2uYtQi0%3D
[Wed Feb 15 14:07:26.633364 2023] [proxy_fcgi:error] [pid 151677:tid 139783988729600] [client 192.0.101.53:3272] AH01071: Got error 'PHP message: PHP Notice:  Unknown: file created in the system's temporary directory in Unknown on line 0', referer: https://lancecleveland.com/?rest_route=%2Fjetpack%2Fv4%2Fbackup-helper-script&_for=jetpack&token=fJJqXO%2AOY%24MUalxLbrxIcEo%24X%212vF4%21%28%3A1%3A0&timestamp=1676470046&nonce=8XyYirJt6T&body-hash=KduxMMT1iJJMlm2cC8mSMIcXSPw%3D&signature=nSnoiRenhuygnl8ssjDOmUGgexs%3D
[Wed Feb 15 14:07:28.734460 2023] [proxy_fcgi:error] [pid 142942:tid 139784659785472] [client 192.0.100.70:41300] AH01071: Got error 'PHP message: PHP Notice:  Unknown: file created in the system's temporary directory in Unknown on line 0', referer: https://lancecleveland.com/?rest_route=%2Fjetpack%2Fv4%2Fbackup-helper-script&_for=jetpack&token=fJJqXO%2AOY%24MUalxLbrxIcEo%24X%212vF4%21%28%3A1%3A0&timestamp=1676470048&nonce=pHcK3aLh9z&body-hash=Rz3q3jp5uwaJE6SxETr3GnmS%2BUA%3D&signature=HvOjb%2B05Pl34HQD0IEuHH2OmGZI%3D

After doing some digging online, the problem appears to be that PHP is unable to find or create content in the temp directory that is configured in the “PHP specific” temp directory, which throws the PHP warning above. PHP falls back to then creating the file in the operating system’s default directory at /tmp.

This is likely the source of the problem as it is very likely that the /tmp directory is NOT accessible from public HTTPS endpoints; This is only an assumption at this point while waiting for clarification on the process the Jetpack service is undertaking in the background.

Currently this investigation is still underway. The article will be updated with further discoveries and , hopefully, an ultimate resolution that will be shared with Bitnami and/or Jetpack in the near future.

Have some clues as to what is going on and how to resolve the issue? Let me know in the comments below.

post image vix Pixabay