I have an old Pi3 that had been chugging away for a long time, running a Nextcloud installation (installed from dietpi-software) on lighthhtpd.
I came to realise it had been a long time since I had updated and found that dietpi-update was dropping out with an error.
That was discussed here - https://dietpi.com/phpbb/posting.php?mode=reply&t=9574 - and a couple of very helpful forum members came to my aid. Consequently after following their advice I was able to get dietpi-update to update the system and it is now happily running 7.7.3 - happily, that is, except for Nextcloud.
I can browse to the web service instance (https://) and get the lighthttp landing page, but https:///nexcloud returns an “Internal Server Error”. A bit of browsing around and I found an article suggested to another user that the logs would reveal the cause and in their case it turned out that the service was no longer able to connect to the database. Re-applying the “grant all privileges on . etc…” command fixed it for them. Unfortunately (maybe because this is a DietPi implementation of Nextcloud) the data directory that should contain the log file, doesn’t appear to exist in /var/www/nextcloud on my Pi3
I can access MariaDB from the mysql command, everything looks OK, the Nextcloud database is present and correct and because the host is basically used for nothing more that Nextcloud, there are only two db user accounts, so I performed this ‘grant all privileges’ command against both. Both commands completed without error, but even after a reboot I’m still unable to get into the service.
Given I used dietpi-software to install this service I wondered if there was maybe a way were I could re-install/repair this installation, get it connected to the existing MariaDB database instance and get it back that way?
Of course, any other suggestions would be most welcome 
well usually DietPi update is not breaking existing installations as it just update DietPi scripts. What might happen could be that an apt packages is causing some issues because DietPi is going to trigger apt update && apt upgrade during the update process. Did you tried to reboot your system after the update?
could you share following after a reboot.
dietpi-services status
Hi -
Thank you for your reply.
Yes I did reboot afterwards and did again several times after.
Here is the output for dietpi-services status, as you requested
DietPi-Services
─────────────────────────────────────────────────────
Mode: status
[ OK ] DietPi-Services | redis-server active (running) since Fri 2021-10-22 20:32:12 BST; 15h ago
[ OK ] DietPi-Services | mariadb active (running) since Fri 2021-10-22 20:32:15 BST; 15h ago
[ OK ] DietPi-Services | php7.3-fpm active (running) since Fri 2021-10-22 20:32:16 BST; 15h ago
[ OK ] DietPi-Services | lighttpd active (running) since Fri 2021-10-22 20:32:16 BST; 15h ago
[ OK ] DietPi-Services | cron active (running) since Fri 2021-10-22 20:32:16 BST; 15h ago
[ OK ] DietPi-Services | ssh active (running) since Fri 2021-10-22 20:32:10 BST; 15h ago
[ INFO ] DietPi-Services | dietpi-vpn inactive (dead)
[ OK ] DietPi-Services | dietpi-ramlog active (exited) since Fri 2021-10-22 20:31:58 BST; 15h ago
[ OK ] DietPi-Services | dietpi-preboot active (exited) since Fri 2021-10-22 20:31:58 BST; 15h ago
[ OK ] DietPi-Services | dietpi-postboot active (exited) since Fri 2021-10-22 20:32:10 BST; 15h ago
[ INFO ] DietPi-Services | dietpi-wifi-monitor inactive (dead)
Ok, you could check Nextcloud log file. Have a look for latest entries (timestamp)
cat /mnt/dietpi_userdata/nextcloud_data/nextcloud.log
I’ve found the file you have asked me to look at, but it hasn’t been updated for almost 2 years (Nov 13 2019) -
root@DietPi:/mnt/dietpi_userdata/nextcloud_data# ls -l
total 20
drwxrwxr-x 4 www-data www-data 4096 Nov 13 2019 admin
drwxrwxr-x 3 www-data www-data 4096 Apr 21 2019 appdata_oc4yozw1w0zy
drwxr-xr-x 9 www-data www-data 4096 Nov 13 2019 appdata_ocxo82mubqvx
drwxr-xr-x 2 www-data www-data 4096 Nov 13 2019 files_external
-rwxrwxr-x 1 www-data www-data 0 Nov 13 2019 index.html
-rw-r----- 1 www-data www-data 719 Nov 13 2019 nextcloud.log
That’s I guess the date it has been created. Could you check what is inside.
Sorry, I did. But when I noticed the entries themselves were old, and that there only appeared to be two entries, that’s when I looked at the timestamp of the file which confirmed this.
root@DietPi:/mnt/dietpi_userdata/nextcloud_data# cat nextcloud.log
{"reqId":"9CzsoxcRPtgOHb4CjwwV","level":2,"time":"2019-11-13T12:28:29+00:00","remoteAddr":"10.xxx.xxx.20","user":"--","app":"no app in context","method":"POST","url":"\/nextcloud\/index.php\/login","message":"Login failed: admin (Remote IP: 10.xxx.xxx.20)","userAgent":"Mozilla\/5.0 (Windows NT 6.1; WOW64; Trident\/7.0; rv:11.0) like Gecko","version":"17.0.1.1"}
{"reqId":"JwSCIXkQKNf8i7elmwzD","level":2,"time":"2019-11-13T12:44:17+00:00","remoteAddr":"10.xxx.xxx.20","user":"--","app":"no app in context","method":"POST","url":"\/nextcloud\/index.php\/login","message":"Login failed: phil (Remote IP: 10.xxx.xxx.20)","userAgent":"Mozilla\/5.0 (Windows NT 6.1; WOW64; Trident\/7.0; rv:11.0) like Gecko","version":"17.0.1.1"}
Just looks like two early failures to login.
does switching off maintenance mode give anything back
ncc maintenance:mode --off
Joulinar - continued thanks for your input into this.
That last command might have thrown up something of interest and maybe has brought to light a consequence of having left this installation for as long as I did.
root@DietPi:~# ncc maintenance:mode --off
This version of Nextcloud is not compatible with > PHP 7.3.<br/>You are currently running 8.0.10.
Would this indicate that by running the dietpi-update I’ve ended up with a newer version of PHP that doesn’t support the version of Netcloud that’s in /var/www/nextcloud?
I’ve had a look in /etc/php and it looks as though I have a number of versions present -
root@DietPi:/etc/php# ls -l
total 24
drwxr-xr-x 3 root root 4096 Nov 13 2019 5.6
drwxr-xr-x 5 root root 4096 Apr 21 2019 7.0
drwxr-xr-x 3 root root 4096 Nov 13 2019 7.1
drwxr-xr-x 3 root root 4096 Nov 13 2019 7.2
drwxr-xr-x 5 root root 4096 Nov 13 2019 7.3
drwxr-xr-x 5 root root 4096 Oct 22 20:44 8.0
Would there be a way of rolling back to a previous version PHP to recover access to the Nextcloud instance so that it can be updated?
Ok now we are heading into right direction. Could it be you are running oldold Debian Stretch still? Pls share some more system details
Required Information
- DietPi version | cat /boot/dietpi/.version
- Distro version | echo $G_DISTRO_NAME $G_RASPBIAN
- Kernel version | uname -a
- SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3)
DietPi Version:
G_DIETPI_VERSION_CORE=7
G_DIETPI_VERSION_SUB=7
G_DIETPI_VERSION_RC=3
G_GITBRANCH=‘master’
G_GITOWNER=‘MichaIng’
G_LIVE_PATCH_STATUS[0]=‘applied’
Distro Version:
Stretch 1
Kernel:
Linux DietPi 4.19.66-v7+ #1253 SMP Thu Aug 15 11:49:46 BST 2019 armv7l GNU/Linux
SBC Model:
Pi3B (not B+)
So, even I can work out that it is still probably Stretch. Would an apt dist-upgrade be in order?
Ok basically we would have 2 option
Fix it on Stretch, which I would not recommend. Because Stretch is quite an old Debian version.
Or upgrade the entire system to Buster first and fix PHP version there.
Or upgrade the entire system to Buster first and fix PHP version there
I agree.
So, is that apt dist-upgrade to take it from Stretch to Buster?
Not really. Some more steps are needed. But we have a guide you could follow https://dietpi.com/docs/usage/#how-to-upgrade-to-buster
Most probably PHP will be incorrect still but could be fixed once you on Buster.
Important: create a backup before you start
Many thanks.
I’ve had a quick look at the guide and it appears to be easy enough to follow.
Backup done.
My weekend is over and it will be back to the day job tomorrow, but I will see if I can squeeze this in one evening and get back to you with the outcome.
take your time. No need to rush. 
Hi -
Took a little longer than expected to get back to this as I was unwell last weekend.
Anyway, have gone through the steps you pointed me at to upgrade to Buster and I believe from the output of the previous commands to asked me to run that it has upgraded:-
cat /boot/dietpi/.version
G_DIETPI_VERSION_CORE=7
G_DIETPI_VERSION_SUB=7
G_DIETPI_VERSION_RC=3
G_GITBRANCH='master'
G_GITOWNER='MichaIng'
G_LIVE_PATCH_STATUS[0]='applied'
echo $G_DISTRO_NAME $G_RASPBIAN
buster 1
uname -a
Linux DietPi 5.10.63-v7+ #1459 SMP Wed Oct 6 16:41:10 BST 2021 armv7l GNU/Linux
Was unable to access either the nextcloud instance or the root web service and dietpi-services status indicated that lighthttpd had failed to start. So, performed another reboot which made no difference.
The lighthttps-specific messages returned by dietpi-services status show -
Loaded: loaded (/lib/systemd/system/lighttpd.service; disabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sat 2021-11-06 16:17:59 GMT; 56s ago
Process: 764 ExecStartPre=/usr/sbin/lighttpd -tt -f /etc/lighttpd/lighttpd.conf (code=exited, status=255/EXCEPTION)
Nov 06 16:17:59 DietPi systemd[1]: lighttpd.service: Service RestartSec=100ms expired, scheduling restart.
Nov 06 16:17:59 DietPi systemd[1]: lighttpd.service: Scheduled restart job, restart counter is at 5.
Nov 06 16:17:59 DietPi systemd[1]: Stopped Lighttpd Daemon.
Nov 06 16:17:59 DietPi systemd[1]: lighttpd.service: Start request repeated too quickly.
Nov 06 16:17:59 DietPi systemd[1]: lighttpd.service: Failed with result 'exit-code'.
Nov 06 16:17:59 DietPi systemd[1]: Failed to start Lighttpd Daemon.
So, that’s where I am at the moment.
Let’s verify configuration. It will display the exact error if there is one 
/usr/sbin/lighttpd -tt -f /etc/lighttpd/lighttpd.conf
Don’t know if this is particularly revealing -
root@DietPi:~# /usr/sbin/lighttpd -tt -f /etc/lighttpd/lighttpd.conf
/bin/bash: /usr/share/lighttpd/create-mime.assign.pl: No such file or directory
2021-11-06 17:23:18: (configfile.c.1468) command "/usr/share/lighttpd/create-mime.assign.pl" exited non-zero: 127
2021-11-06 17:23:18: (configfile.c.1296) source: /etc/lighttpd/lighttpd.conf line: 31 pos: 14 parser failed somehow near here: (EOL)
root@DietPi:~#
ah I guess the file has been renamed on newer version of Lighttpd. Let’s check it
ls -la /usr/share/lighttpd/