An Unexpected Error Occurre – SOLVED

No comments

Solved: WordPress – “An unexpected error occurred.” when installing plugins, themes, and more.

Problem

Attempting to add things to WordPress like plugins or themes causes the following error:

An unexpected error occurred. Something may be wrong with WordPress.org or this server’s configuration. If you continue to have problems, please try the support forums.

Solution

Check your SELinux audit logs for signs of denials. Your web server software (probably Apache / https) or a module being used by the software is most likely having outbound connection attempts denied.

You’ll probably want to read through Red Hat Enterprise Linux’s documentation on SELinux. However, in the absence of that enormous task, at least read through “Allowing Access: audit2allow” and understand the basics of allowing blocked actions in SELinux. Please do not disable SELinux. That’s a bad habit. SELinux is your friend and wants to protect you.

And you’re likely solution will involved installing the Python utilities to manage SELinux:

yum install policycoreutils-python-utils

Then you’ll want to run audit2allow -w -a to determine what is being blocked in the recent past. It may take some sleuthing to correlate the blocked behavior that WordPress is attempting to perform from other blocked behavior on the Linux host. I recommend  tailing your audit log, and then immediately attempting to perform whatever action is being blocked in WordPress.

tail -f /var/log/audit/audit.log

You should immediately see what’s being blocked, and then have a better idea of how to interpret audit2allow -w -a.

Lastly, create the exception based on what audit2allow -w -a has shown you by using audit2allow -a -M your_module_name and then semodule -i your_module_name.pp. In my case, my final solution was:

grep php-fpm /var/log/audit/audit.log | audit2allow -a -M apache_php_fpm
semodule -i apache_php_fpm.pp

The Long Story

What better way to kick off a fresh blog than with a WordPress problem to work through. On a fresh install Of WordPress 4.9.8, I was unable to perform actions like adding a theme or plugin via the GUI. The error was:

An unexpected error occurred. Something may be wrong with WordPress.org or this server’s configuration. If you continue to have problems, please try the support forums.

Welp, that’s unfortunate. I tailed Apache’s logs when I unsuccessfully tried adding a theme or plugin and didn’t see anything useful. Next I turned on WordPress’s debugging by adding the following to my wp-config.php file:

define( 'WP_DEBUG', true );

With that added, I got a slightly more verbose error to look at:

An unexpected error occurred. Something may be wrong with WordPress.org or this server’s configuration. If you continue to have problems, please try the support forums.

(WordPress could not establish a secure connection to WordPress.org. Please contact your server administrator.) in /path/to/my/webroot/wp-includes/update.php on line 529

Hmm… a secure connection couldn’t be established, you say? Sounds vaguely TLSy to me. Let’s take a look at line 529 in update.php to see if we can get a bit more context.

522         if ( $ssl && is_wp_error( $raw_response ) ) {
523                 trigger_error(
524                         sprintf(
525                                 /* translators: %s: support forums URL */
526                                 __( 'An unexpected error occurred. Something may be wrong with WordPress or this server’s configuration. If you continue to have problems, please try the support forums.' ),
527                                 __( 'https://wordpress.org/support/' )
528                         ) . ' ' . __( '(WordPress could not establish a secure connection to WordPress.org. Please contact your server administrator.)' ),
529                         headers_sent() || WP_DEBUG ? E_USER_WARNING : E_USER_NOTICE
530                 );
531                 $raw_response = wp_remote_post( $http_url, $options );
532         }

Well would you look at that. Looks like there’s something up with SSL/TLS after all. A quick check of phpinfo() told me that openssl was a loaded module, and enabled. Curl had SSL support. Everything looked okay, but one thing caught my eye:

openssl.cafile: no value
openssl.capath: no value

That seems odd to me. However after some research, I understood it and realized that in my case, it wasn’t an issue.

Another lead I followed up on was IPv4/IPv6 issues with the host that WordPress was installed on. After some quick tests, I realized that IPv6 was working on my host, and didn’t seem likely as a culprit.

And then it hit me. What are the two most common things that stop network applications from running on a Linux host? A firewall and SELinux. I quickly disabled the firewall and tested. Nope, still didn’t work. I quickly put SELinux into permissive mode and WordPress was able to install themes and plugins.

A quick perusal of /var/log/audit/audit.log showed telltale lines like this:

type=AVC msg=audit(1535785841.801:64633): avc:  denied  { name_connect } for  pid=24056 comm="php-fpm" dest=443 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket permissive=0

I made sure that policycoreutils-python-utils was installed on my RedHat-based server and then used audit2allow to allow php-fpm the needed access. First I observed the logged SELinux denials with audit2allow -w -a:

type=AVC msg=audit(1535786491.988:64654): avc:  denied  { name_connect } for  pid=24627 comm="php-fpm" dest=443 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket permissive=0
        Was caused by:
        One of the following booleans was set incorrectly.
        Description:
        Allow httpd to can network connect

        Allow access by executing:
        # setsebool -P httpd_can_network_connect 1
        Description:
        Allow httpd to graceful shutdown

        Allow access by executing:
        # setsebool -P httpd_graceful_shutdown 1
        Description:
        Allow httpd to can network relay

        Allow access by executing:
        # setsebool -P httpd_can_network_relay 1
        Description:
        Allow nis to enabled

        Allow access by executing:
        # setsebool -P nis_enabled 1

And next I used audit2allow to allow access. In my specific case, I inspected the rules that would be created by running:

grep php-fpm /var/log/audit/audit.log | audit2allow -a

I then created a SELinux module from that subset of audit failures with:

grep php-fpm /var/log/audit/audit.log | audit2allow -a -M apache_php_fpm

And finally I loaded the module:

semodule -i apache_php_fpm.pp

After that, WordPress was able to perform operations that required it to make connections to remote hosts, such as installing plugins and themes from the GUI.

Rate this post