Apache won't serve local websites after latest update

[DrMartinus]

After the last upgrade about a week ago I noticed that my local host webpages weren’t displayed, but due to other work which kept me busy I wasn’t following it up. Now I do, and I need help. I browsed through the internet for solutions but didn’t find any conclusive ones.

This is what happened so far:

1. I found out that httpd hadn’t started, it reported an error in httpd.conf of a surprising kind: the webserver folder which is within my home was not available, it “is not a directory, or is not readable” (that was no problem until one or two weeks ago)
2. I searched and found that at some point apache was supposedly changed to not allow access to websites hosted within the home folder (any more)
3. I then changed in the httpd.conf file the website folder to the default /srv/http and created a symlink, which points to my websites in the home folder. I also changed the <Directory…> sections in httpd.conf
4. Now apache started (systemctl restart httpd), the result of systemctl status httpd is just fine.
5. But I cannot access the websites, I get a 403 error. In the /var/log/httpd/error.log it says: Symbolic link not allowed or link target not accessible: /srv/http/webservertest

The httpd.conf section relating to this says:

<Directory “/srv/http”>
  Options Indexes FollowSymLinks
  AllowOverride None
  Require all granted
</Directory>

<Directory  “/srv/http/webservertest”>
  Require all granted
  Order allow,deny
  Allow from localhost
  Allow from 127.0.0.1
</Directory>

The websites use php, and php seems to be active according to the footer of the website which presents the 803 error.

What can be wrong?

[beermad]

This has been covered by threads here before; if you search you’ll find full details.
Essentially it’s that Apache’s systemd service file now includes

NoNewPrivileges=on
PrivateDevices=on
PrivateTmp=on
ProtectHome=on

So one or more needs to be overridden, dependent on your setup.

[linux-aarhus]

@DrMartinus

What can be wrong?

Nothing is wrong.

Apache service configuration has been hardened by upstream and you have to adjust the configuration.

hardening.conf · main · Arch Linux / Packaging / Packages / apache · GitLab

Edit the override in /etc/systemd/system to suit your local requirements.

/etc/systemd/system/httpd.service.d/hardening.conf

[DrMartinus]

Thank you both for pointing this out. I had been searching but didn’t find anything helpful. It was probably the wrong search. It’s sometimes not so easy to find the right words in order to get the right results. Sorry for any inconvenience.

I still wish that such changes would be pointed out more clearly. I only had noticed that the httpd.conf had been changed, and I put the individual settings back in, but the hardening isn’t mentioned in the last upgrade notes and, as said, I didn’t find anything about it (besides the mentioning that apache doesn’t serve from /home/ any more).

Well, thank you very much, it works now.

[tracyanne]

@DrMartinus

Well, thank you very much, it works now.

You might want to assign a tick to the reply that best fits your solution, so others can discover this.

[freggel.doe]

@DrMartinus

I still wish that such changes would be pointed out more clearly.

It was mentioned in the latest Announcements > Stable Updates thread:

[Stable Update] 2025-09-26 - Kernels, NVIDIA, Systemd, LibreOffice, KDE Software

Apache could not serve local files. The error log contained a familiar error message, “…because search permissions are missing on a component of the path…”, but with a new reason introduced with this update. /etc/systemd/system/httpd.service.d/hardening.conf was not in Apache 2.4.63, but is in Apache 2.4.65. The systemd directive ProtechHome is set to on. A solution is to change the value for ProtectHome to off. After the change, reload daemon-reload and restart httpd.

[Stable Update] 2025-09-26 - Kernels, NVIDIA, Systemd, LibreOffice, KDE Software

Just to prevent misunderstantings: it absolutely can serve local files, just not from a users home directory. There is also ProtectHome=read-only where httpd might read the files but won’t be able to write any, see:

[DrMartinus]

@freggel.doe

It was mentioned in the latest Announcements > Stable Updates thread:

Ok, I use testing and receive the link to the announcements for testing. I didn’t think of looking into announcements for stable updates, as I thought all is covered in the announcements for testing updates. Well, one never stops learning (and I hope I remember for next time…)

[beermad]

@DrMartinus

Ok, I use testing and receive the link to the announcements for testing. I didn’t think of looking into announcements for stable updates, as I thought all is covered in the announcements for testing updates. Well, one never stops learning (and I hope I remember for next time…)

To be fair, probably only a limited number of people (myself included) actually put their files in locations that would be hit by this change. And I’d assume the number of people on the testing branch will be far smaller than those on the main one, so with a small percentage of a small percentage zero is highly probable.

I suspect barring services from accessing certain parts of the filesystem may become more and more common; it happened with MariaDB a couple of years ago (and that confused me). It probably makes sense to restrict access for services that might be open to the wider Internet.