* What led up to the situation? I updated to 2.4.65-4 in Testing. * What was the outcome of this action? The server won't start and the following error is logged [:error] ... (30)Read-only file system: AH10082: Can't change owner of /etc/apache2/md/challenges [md:error] ... (30)Read-only file system: AH10047: setup challenges directory AH00016: Configuration Failed The cause? This, from NEWS.Debian.gz ProtectSystem is set to full by default; this mounts various system paths like /usr, /boot and /etc as read-only, enhancing overall system integrity. /etc/ is mounted read-only but apache module mod_md (included in package apache2) seems to need to write to /etc/apache2/md/challenges/). Maybe I should mention that I use Let's Encrypt certificates By the way, according to https://httpd.apache.org/docs/2.4/mod/mod_md.html "This module requires mod_watchdog to be loaded as well" I haven't been able to find mod_watchdog in the Testing repository. Is that information obsolete? I'm filing this against apache2 because mod_md is included in that package.
control: tags -1 + moreinfo control: severity -1 important Le vendredi 9 janvier 2026, 13:21:32 heure normale d’Europe centrale Juan-Rafael Fernandez a écrit : Yes but normally it store at root of document... what is your mod_md configuration ? rouca
control: tags -1 + moreinfo control: severity -1 important Le vendredi 9 janvier 2026, 13:21:32 heure normale d’Europe centrale Juan-Rafael Fernandez a écrit : Yes but normally it store at root of document... what is your mod_md configuration ? rouca
I don't know if there's specific configuration for mod_md. I haven't touched anything in the apache2 configuration. By the way my /etc/apache2/md/ subdirectories were created in 2017. And no change in /etc/letsencrypt/ since November either, and they were only changes to the SSLProtocol and SSLCipherSuite directives. The only relevant new things were upgrading apache2, which brings ProtectSystem full, and starting to use Mullvad VPN, with nftables problems I have to solve. If you need further information please just tell me what specific files to send. Maybe an exception permitting writing in /etc/apache2/md/challenges/ would solve the problem?
I don't know if there's specific configuration for mod_md. I haven't touched anything in the apache2 configuration. By the way my /etc/apache2/md/ subdirectories were created in 2017. And no change in /etc/letsencrypt/ since November either, and they were only changes to the SSLProtocol and SSLCipherSuite directives. The only relevant new things were upgrading apache2, which brings ProtectSystem full, and starting to use Mullvad VPN, with nftables problems I have to solve. If you need further information please just tell me what specific files to send. Maybe an exception permitting writing in /etc/apache2/md/challenges/ would solve the problem?
Le vendredi 9 janvier 2026, 17:43:03 heure normale d’Europe centrale Juan Rafael Fernández García a écrit : No the solution is to move this directory to /var/cache/apache2 What is the output of - dpkg -L apache2 - dpkg -S /etc/apache2/md rouca
/etc/apache2/md contains other files that need to be writable. I fail to see how ProtectSystem=full can work there with the defaults of mod_md. Chris
Le vendredi 9 janvier 2026, 17:43:03 heure normale d’Europe centrale Juan Rafael Fernández García a écrit : No the solution is to move this directory to /var/cache/apache2 What is the output of - dpkg -L apache2 - dpkg -S /etc/apache2/md rouca
certbot, python3-certbot or python3-certbot-apache. So maybe /etc/apache2/md/ is a remnant of an old version (I have been updating Debian Testing on this computer since 2017). Then I had the idea of renaming /etc/apache2/md/ to /etc/apache2/md_removed/. The error has changed [md:error] ... (30)Read-only file system: AH10046: setup store for /etc/apache2/md AH00016: Configuration Failed
certbot, python3-certbot or python3-certbot-apache. So maybe /etc/apache2/md/ is a remnant of an old version (I have been updating Debian Testing on this computer since 2017). Then I had the idea of renaming /etc/apache2/md/ to /etc/apache2/md_removed/. The error has changed [md:error] ... (30)Read-only file system: AH10046: setup store for /etc/apache2/md AH00016: Configuration Failed
Le vendredi 9 janvier 2026, 18:57:02 heure normale d’Europe centrale Juan Rafael Fernández García a écrit : grep -R /md on the apache2 directory will help to identify the configuration. In all the case this kind of configuration should go to /var/cache/apache2 (exactly /var/cache/apache2/md) And existing configaration should be moved on it.... But it depends how this was created for your case move the /etc/apache2/md directory to /var/cache/md and create a symlink from /etc/apache2/md to /var/cache/md and restart
Nothing relevant. Where's the configuration of mod_md, in /etc/letsencrypt maybe? It worked! Now the server is listening. Thanks a lot. Is it just me with /etc/apache2/md/? I still don't know how those files were created in 2017.
control: forwarded -1 https://github.com/icing/mod_md/issues/402 Le vendredi 9 janvier 2026, 19:43:32 heure normale d’Europe centrale Juan Rafael Fernández García a écrit : Do not know but for me only sysadmin could create something under /etc, so it is an upstream bug that should be solved reported and waiting from upstream rouca
Hi everyone, FWIW: If OP doesn't actually *use* mod_md for certificate handling (by having at least an MDomain directive anywhere), he should just do `a2dismod md` and restart the server and it should work as before. As I'm a heavy user of mod_md, I'll chime in here with some background info. mod_md implements the ACME protocol for certificate handling in Apache httpd itself. It is written in pure C and does not use the python packages mentioned earlier like certbot does. It does not need nor touch the /etc/letsencrypt directory. For its own storage requirements, there is [1]: (Keep in mind that server root != document root!) Furthermore, mod_md uses that directory not only to store challenge content (in md/challenges) (which is only temporary), but also the ACME account data (md/accounts) as well as the actual certificates (md/domains, md/archive) - including some intermediate steps while requesting (md/staging, md/tmp) and OCSP data (md/ocsp). So for some of the content, /var/cache might be appropriate (although it could even be an actual tmpdir), but for others, it should at least be /var/lib, if you are insistent on not having it write in /etc. Also, IMHO, the current content of /etc/apache2/md needs to be copied/moved to any alternate location that we decide on... Or at least acknowledge mod_md explicitly in the NEWS entry for requiring additional setup in the systemd.service and encourage the user to move the directory itself? Best regards, Moritz [1]: https://httpd.apache.org/docs/current/mod/mod_md.html#mdstoredir