Can't enable/disable or add/delete adlists after update

Expected Behaviour:

I can enable/disable and add/delete adlists as I wish.

Device model : RPi 3 Model B+ (armv7l)
OS: DietPi v8.3.1
Pi-hole version is v5.10 (Latest: v5.10)
AdminLTE version is v5.12 (Latest: v5.12)
FTL version is v5.15 (Latest: v5.15)

Actual Behaviour:

Trying to enable/disable or add/delete adlists results in an error message. For example trying to delete a list throws "Error, something went wrong! While executing adlist_by_group statement: attempt to write a readonly database". I think the last update of DietPi or PiHole broke some user rights, but have no idea how to fix it.
Here is an excerpt of the error log:

   2022-04-30 22:50:46: (mod_compress.c.548) creating cachefile /var/cache/lighttpd/compress//admin/scripts/pi-hole/js/ip-address-sorting.js-gzip-384267-3003-1651315337947952538 failed Read-only file system
   2022-04-30 22:50:46: (mod_compress.c.548) creating cachefile /var/cache/lighttpd/compress//admin/scripts/pi-hole/js/queries.js-gzip-384099-16934-165131529897952553 failed Read-only file system
   2022-04-30 22:50:52: (mod_compress.c.548) creating cachefile /var/cache/lighttpd/compress//admin/scripts/vendor/daterangepicker.min.js-gzip-384299-32667-1651315337987952538 failed Read-only file system
   2022-04-30 22:50:52: (mod_compress.c.548) creating cachefile /var/cache/lighttpd/compress//admin/scripts/pi-hole/js/db_graph.js-gzip-384093-12150-165131529887952553 failed Read-only file system
   2022-04-30 22:51:11: (chunk.c.551) opening temp-file failed: /var/cache/lighttpd/uploads/lighttpd-upload-zgd1So Input/output error
   2022-04-30 22:51:23: (chunk.c.551) opening temp-file failed: /var/cache/lighttpd/uploads/lighttpd-upload-Y0BsRN Input/output error
   2022-04-30 22:51:35: (chunk.c.551) opening temp-file failed: /var/cache/lighttpd/uploads/lighttpd-upload-7Cz7Cm Input/output error
   2022-04-30 22:51:47: (chunk.c.551) opening temp-file failed: /var/cache/lighttpd/uploads/lighttpd-upload-EVzFH0 Input/output error
   2022-04-30 22:52:17: (chunk.c.551) opening temp-file failed: /var/cache/lighttpd/uploads/lighttpd-upload-PNkTjB Input/output error
   2022-04-30 22:52:29: (mod_compress.c.548) creating cachefile /var/cache/lighttpd/compress//admin/style/vendor/animate.min.css-gzip-384333-58129-16513153387952538 failed Read-only file system
   2022-04-30 22:52:29: (mod_compress.c.548) creating cachefile /var/cache/lighttpd/compress//admin/style/vendor/bootstrap-select.min.css-gzip-384334-11179-16513153387952538 failed Read-only file system
   2022-04-30 22:52:29: (mod_compress.c.548) creating cachefile /var/cache/lighttpd/compress//admin/style/vendor/bootstrap-toggle.min.css-gzip-384336-1590-16513153387952538 failed Read-only file system
   2022-04-30 22:52:29: (mod_compress.c.548) creating cachefile /var/cache/lighttpd/compress//admin/scripts/vendor/bootstrap-select.min.js-gzip-384294-52981-1651315337977952538 failed Read-only file system
   2022-04-30 22:52:29: (mod_compress.c.548) creating cachefile /var/cache/lighttpd/compress//admin/scripts/vendor/bootstrap-toggle.min.js-gzip-384296-4129-1651315337977952538 failed Read-only file system
   2022-04-30 22:52:29: (mod_compress.c.548) creating cachefile /var/cache/lighttpd/compress//admin/scripts/pi-hole/js/groups-domains.js-gzip-384263-16453-1651315337937952538 failed Read-only file system
   2022-04-30 22:52:36: (mod_compress.c.548) creating cachefile /var/cache/lighttpd/compress//admin/scripts/pi-hole/js/queryads.js-gzip-384270-2439-1651315337947952538 failed Read-only file system
   2022-04-30 22:54:32: (mod_compress.c.548) creating cachefile /var/cache/lighttpd/compress//admin/scripts/pi-hole/js/messages.js-gzip-384098-10862-165131529897952553 failed Read-only file system
   2022-04-30 22:57:43: (mod_compress.c.548) creating cachefile /var/cache/lighttpd/compress//admin/scripts/pi-hole/js/auditlog.js-gzip-384253-4695-1651315337927952538 failed Read-only file system
   2022-04-30 22:58:06: (mod_compress.c.548) creating cachefile /var/cache/lighttpd/compress//admin/scripts/pi-hole/js/groups-adlists.js-gzip-384261-16024-1651315337937952538 failed Read-only file system
   2022-04-30 22:59:14: (mod_fastcgi.c.421) FastCGI-stderr: PHP message: PHP Warning:  SQLite3Stmt::execute(): Unable to execute statement: attempt to write a readonly database in /var/www/html/admin/scripts/pi-hole/php/groups.php on line 1142
   2022-04-30 22:59:24: (mod_fastcgi.c.421) FastCGI-stderr: PHP message: PHP Warning:  SQLite3Stmt::execute(): Unable to execute statement: attempt to write a readonly database in /var/www/html/admin/scripts/pi-hole/php/groups.php on line 1142
   2022-04-30 23:01:52: (mod_fastcgi.c.421) FastCGI-stderr: PHP message: PHP Warning:  SQLite3Stmt::execute(): Unable to execute statement: attempt to write a readonly database in /var/www/html/admin/scripts/pi-hole/php/groups.php on line 1142
   2022-04-30 23:03:47: (mod_fastcgi.c.421) FastCGI-stderr: PHP message: PHP Warning:  SQLite3Stmt::execute(): Unable to execute statement: attempt to write a readonly database in /var/www/html/admin/scripts/pi-hole/php/groups.php on line 1142
   2022-04-30 23:04:08: (mod_fastcgi.c.421) FastCGI-stderr: PHP message: PHP Warning:  SQLite3Stmt::execute(): Unable to execute statement: attempt to write a readonly database in /var/www/html/admin/scripts/pi-hole/php/groups.php on line 1080
   2022-04-30 23:04:20: (mod_compress.c.548) creating cachefile /var/cache/lighttpd/compress//admin/scripts/pi-hole/js/groups.js-gzip-384264-8156-1651315337937952538 failed Read-only file system

Debug Token:

https://tricorder.pi-hole.net/dloY52iY/

So... how do I fix this?

It would seem you are running on a read-only file system.

To successfully apply any updates, you'd have to allow read-write access at least temporarily.

In general, I would not recommend to run your Pi-hole on a read-only file system (specifically, Pi-hole won't be able to write to its query and gravity databases).

If you are not using a read-only file system by intention, then your OS may have enforced read-only access to due OS-level file system corruption.
In that case, check your SD card and replace if required.

It wasn't read-only before updating yesterday morning. :confused:

So if the sd-card is faulty, that would be the second one to break within three years. Is it normal for a Raspberry Pi only running a PiHole to eat a sd-card every 1.5 years? Would it be more stable if I used an USB-stick instead of a sd-card?

That's more of a generic question than Pi-hole related.

File system corruption does not necessarily mean that the SD card would be defective.
Beside such a h/w defect, that could also happen if you cut the power from your RPi without properly shutting it down before, or if the RPi can't supply enough power when writing to the card, e.g. because of an insufficient PSU or power cable, or if other peripherals connected to your RPi would draw more power than the board could provide at peak times.

You may check your RPi’s log for recent under-voltage warnings:

sudo zgrep -ni “voltage” /var/log/syslog*

If you have power issues, you should address them first.

In addition, you could try to remount the file system in read-write mode and attempt to repair it (e.g. by using fsck).

1 Like

I'm an idiot. When I switched from the Pi Zero to the 3B+, I didn't think about the increased power demand and just continued to use the USB port of my router, which only delivers 0.5A. Switching the cable to the charging port of my NUC, which delivers the needed 1.5A, should fix the issue in the future. I'm surprised it didn't fail earlier!

Thank you so much for you help!

Often insufficient power isn't recognised until heavier tasks are done, like APT upgrades (as part of the DietPi update).

For completeness, if no rsyslog is installed, to generally check for kernel errors, including voltage-related and filesystem errors:

dmesg -l emerg,alert,crit,err

And on RPi there is a firmware command to check for under-voltage and thermal throttling events:

vcgencmd get_throttled

Result is 0x0 if everything is and was fine in this boot session. You'd see e.g. 0x50000 in case an under-voltage was detected an CPU frequency in turn capped since last boot, or 0x50005 if this is still the case now. More details: Monitoring Raspberry Pi Power and Thermal Issues

To check and in case repair the root filesystem, this can be done on reboot:

> /forcefsck
reboot

Empty redirect via > is intended here to create the empty flag for /forcefsck.

1 Like

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.