with respect to the index corrupted I get confused, because
> check table oc_activity;
+--------------------------+-------+----------+----------+
| Table | Op | Msg_type | Msg_text |
+--------------------------+-------+----------+----------+
| db_name.oc_activity | check | status | OK |
+--------------------------+-------+----------+----------+
Are you sure? Try to run:
SELECT * FROM oc_appconfig;the SELECT command works on oc_appconfig shows 262 rows in my db.
I note that in the table the core information is wrong
| core | lastupdateResult | {"version":"19.0.4.2","versionstring":"Nextcloud 19.0.4","url":"https:\/\/download.nextcloud.com\/server\/releases\/nextcloud-19.0.4.zip","web":"https:\/\/docs.nextcloud.com\/server\/19\/admin_manual\/maintenance\/upgrade.html","changes":"https:\/\/updates.nextcloud.com\/changelog_server\/?version=19.0.4","autoupdater":"1","eol":"0"} |
ok, so the database backup that I use was initiated after trying to install 19.04. but that install was aborted… Also, also, the maintenance stuck issue is still the case, even if I upgrade to 19.04. or even to 20.
Should I provide the details of the oc_appconfig table?
I am running in to the same issue with the MSQL upgraded issue. I am upgrading form 19.02 to 19.03. The error I am runinning in to see a Attachment. I really don want to delete my nextcloud where I am now just to keep up with a new up grade. Can some one look at the error attached and my be let me know what I should do next.
Thanks.AFAICS you have changed the database backup version between your posts, so i don’t know the current state. As I have said, you need to restore the state of db that matches your files. I am assuming that you have backups of dbs for the different versions of NC.
Find out what NC version your current db belongs to. Find out which version of files you are using in config/config.php and compare them. I am not sure about config.php, maybe it was already changed although the update didn’t finish.
I just remembered this: Check /var/www/nextcloud/data/updater-…/ for backups of NC files.
If you can’t do that at this point its probably easier to reinstall Nextcloud and let it scan files again. I don’t know what other apps and data you have except files.
Also, it is hard to understand what you are writing. If English is not your native language, i suggest you post in one of the international channels here.
good luck
The above has worked on all previous instances on docker compose, sorry it seems not to work on your bare metal and for NextCloud v20.
With some help of a friend we have figured out that you need to turn off the maintenance mode in ~/config.php manually. It should reside in /var/www/html/config/config.php
Open with your favourite text editor.
You will find a line:
’maintenance’ => true,
this needs to be changed to
’maintenance’ => false,
Save and exit.
You can probably do it with a command like this, too:
sudo -u www-data php /var/www/nextcloud/occ maintenance:mode --off
But I suggest to change it manually.
For reference to those running NextCloud in a docker image (our setup is using nextcloud:fpm-alpine docker container) here it worked to do:
docker exec -it -u www-data YOUR_DOCKER-CONTAINER_ID sh -c ‘php ./occ maintenance:mode --off’
Hopefully this will also work on your end!
Final note: your config.php looks corrupted as the line ‘maintenance’ shows up twice. Maybe a clean install will help a lot and then move your backed up data in again.
Thanks PancakeConnaisseur.
I was answering to ilippert. i think, you should create a new thread for your problem. This is probably why nobody has answered you yet. Then please provide an output of your log or at least click on the “Detailed Log” think in the webpage you screenshot. It might give you hints on what went wrong.
Hi all,
after days of resetting to the original database, resetting to earlier database backups, and original file structures, updated file structures… the following simple change was the solution.
Remove the complete maintenance line from the config file.
'maintenance' => false,
then it worked.
p.s. I had checked several times for multiple lines of the maintenance entry - no! Only one existed.
Did you removed both of them?
yes, all mentions of maintenance removed.
This is how it should work, however I also got stuck. Only removing the maintenance line alltogether got the instance accessible again. I’d assume its a bug.
Just a guess from what i read here: I could imagine the problem beeing the string ‘false’, which will be true on a boolean evaluation.
So in case someone stumbles by here and having the same error: It would be interesting if the config lists boolean false or string ‘false’ and if removing the dashes solves the problem. (and then of course where the upgrade got stuck, to track where it comes from etc.)
Indeed,
php occ config:system:set maintenance --value=false does not equal php occ config:system:set maintenance --value=false --type=bool. So I now always need to tell occ that the type is bool, and then it works.
Well - then the solution is probably to use occ maintenance:mode --off which should handle that for you
Restart php - the only thing works for me
I tried the same but nothing changed.
I suppose some cache files are internally maintenained at /tmp.
I tried rebooting the server and it worked 
@fwolfst : I tried rebboting the server . Since it is maintaining some temporary files in its /tmp directory.
