0

My WordPress multisite installation was just fine until today.

This morning, I decided to move the contents of my web-server from /var/www/html/ to /var/www/.

I grep'd for any files that had /var/www/html/ hard-coded, and dumped my WordPress MySQL database to check for any links to it. The only file I found in /var/www/html/wordpress/ that had it was the WPCACHEHOME entry in wp-config.php, so I changed that. The only references in the WordPress database was for the recently_edited entry, so there was no need to change it.

After moving /var/www/html/* to /var/www/ and adjusting all of the paths in the Apache config file to point to /var/www/ instead of /var/www/html/, I restarted the server and checked it. Other webpages are okay, but going to example.com/wordpress/ throws a 403 (forbidden) error.

I checked everything I could think of and did a web-search for "wordpress multisite 403" and checked everything people have suggested (90% were about permissions and 9.9% about .htaccess), but nothing worked. I gave up and put everything back the way it was, but it's still giving a 403.

I can access admin pages, as well as other blogs (e.g., example.com/wordpress/foobar/), it's only the primary blog (example.com/wordpress/) that gives a 403. Even example.com/wordpress/index.php gives the same error.

Here's what I've checked, tested, tried, and confirmed:

  • ✓ Browser cache cleared
  • ✓ Owner and group of /var/www/ and everything under it is www-data
  • ✓ Permissions of all directories under www are 775
  • ✓ Permissions of all files (that should be accessible) under www are 664
    • (No, setting them to 755 and 644 respectively won't fix it.)
  • ✓ Apache service has been restarted
  • ✓ Apache config file is correct
  • ✓ Web-server has been rebooted
  • wp-config.php is correct
  • ✓ All paths include trailing slash (/var/www/html/)
  • .htaccess hasn't been modified, but I tried renaming it anyway, as well as replacing it with a new, confirmed-correct copy for WPMU
  • wordpress/index.php is indeed present and unmodified
  • ✓ WordPress database has not been touched since it was last working
  • ✓ No changes made to WPMU format (subdirectories/subdomains)
  • ✓ The only files under wordpress/ that were modified are wordpress/wp-config.php (restored)
  • ✓ The directories in wordpress/wp-content/cache/ were deleted (blogs, autoptimize, and supercache) but recreated with correct permissions and owners (Autoptimize recreated directories and files in its folder)
  • ✓ There are no directories with the same name as the problem blog (it's the primary blog so what would that even be, /var/www/html/blogs//? 🤨)

Does anyone have any ideas about what could be the problem or suggest things to try?

  • The page in question is a "directory" rather than a file, so I figured I'd look into options to control that. DirectoryIndex is already being used and is set correctly, so I looked at DirectoryIndexRedirect. I tried a few settings and it started working when I set it to off. This is confusing because it used to work without it, and the other blogs example.com/blogs/foobar/ worked without it. 😕 I'll monitor the situation for a while and see what happens. – Synetech Sep 10 '19 at 15:25
  • I'm sure you'll figure it out. Please be sure to post the solution here as others would benefit from it. One question: does DirectoryIndex point to a real file and if so, which one? – Ted Stresen-Reuter Sep 11 '19 at 6:33
0

403 forbidden is an HTTP error. It means the web server does not have the necessary permissions to read the requested file. There is no question about this and you should focus on this before investigating other potential misconfigurations.

Depending on the type of server you are using and in addition to resolving filesystem permissions, you may also have to resolve permission issues in SELinux if you are on RedHat or similar.

Normally, the exact error will be in the HTTP error log (/var/log/apache2/example.com-error or similar). The fact that you say you still have the error even though you moved everything back the way it was, suggests to me that file ownership changed and it is still a filesystem permission issue. To verify, you can view the apache .conf file to see what user apache is running as and make sure that that user also owns the files or is in the same group as the user you are using to move files around.

grep -R -E '^User ' /etc/apache2/* to find out what user apache is configured to run as.

If you are certain file ownership and permissions are correct, it is still possible that apache is looking in the wrong place for the files and, not finding any, is somehow refusing any access. Check the logs. That's where the answer will most likely be.

HTH

  • 403 forbidden is an HTTP error. It means the web server does not have the necessary permissions to read the requested file. There is no question about this and you should focus on this before investigating other potential misconfigurations…it is still possible that apache is looking in the wrong place for the files and, not finding any Except that the "file" in question is not a real file on the disk which the OS has access-control over or which apache can find, it's a virtual file being generated by WordPress. I turned off any caching plugins to mitigate this issue and it still happens. – Synetech Sep 10 '19 at 15:02
  • index.php is a real file so unless your server is configured to use something else as the index file (default.php?) it's a place to start. Also, have you checked the Apache error logs as suggested? And finally, WordPress is indeed often configured to run all requests through index.php, but that is a real file and must exist for it to work. – Ted Stresen-Reuter Sep 10 '19 at 19:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.