Nextcloud version (eg, 20.0.5): 22 (latest 22 update, I’m always up to date)
Operating system and version (eg, Ubuntu 20.04): Ubuntu 20.04
Apache or nginx version (eg, Apache 2.4.25): lightttpd 1.4.55
PHP version (eg, 7.4): 7.4
The issue you are facing:
The Overview page told me an upgrade to 23 was available.
I did what I always do, and clicked Update
It did what it always does but then crashed presenting:
The specific error is vague. The Nextcloud.log file contains no extra information alas to identify the error. My Postgresql log is more informative (after several retries) I see:
2021-12-01 09:19:31.091 AEDT [532901] nextcloud@nextclouddb ERROR: relation "user_id" already exists
2021-12-01 09:19:31.091 AEDT [532901] nextcloud@nextclouddb STATEMENT: CREATE UNIQUE INDEX user_id ON oc_profile_config (user_id)
2021-12-01 09:22:34.051 AEDT [532930] nextcloud@nextclouddb ERROR: relation "user_id" already exists
2021-12-01 09:22:34.051 AEDT [532930] nextcloud@nextclouddb STATEMENT: CREATE UNIQUE INDEX user_id ON oc_profile_config (user_id)
2021-12-01 09:35:30.682 AEDT [533433] nextcloud@nextclouddb ERROR: relation "oc_circle_circles" does not exist at character 15
2021-12-01 09:35:30.682 AEDT [533433] nextcloud@nextclouddb STATEMENT: SELECT * FROM "oc_circle_circles"
2021-12-01 09:35:30.685 AEDT [533433] nextcloud@nextclouddb ERROR: relation "oc_circle_members" does not exist at character 15
2021-12-01 09:35:30.685 AEDT [533433] nextcloud@nextclouddb STATEMENT: SELECT * FROM "oc_circle_members"
2021-12-01 09:35:31.353 AEDT [533433] nextcloud@nextclouddb ERROR: relation "oc_circle_tokens" does not exist at character 15
2021-12-01 09:35:31.353 AEDT [533433] nextcloud@nextclouddb STATEMENT: SELECT * FROM "oc_circle_tokens"
2021-12-01 09:36:56.741 AEDT [533457] nextcloud@nextclouddb ERROR: relation "user_id" already exists
2021-12-01 09:36:56.741 AEDT [533457] nextcloud@nextclouddb STATEMENT: CREATE UNIQUE INDEX user_id ON oc_profile_config (user_id)
Is this the first time you’ve seen this error? (Y/N): Y
Or not. I seem to recall coming across this database error before. But it’s a deja vu feeling.
This has killed our nextcloud so I’m keen to get it operational again ASAP. I appreciate any support and help here. I will take a look at that table and see what I can find in the mean time.
This table does not even exist in my Nextcloud database! Ain’t that fun. I wonder what is up here. My gut feel is this is a new table in Nextcloud 23, the updater runs in a transaction, which it rolls back when the exception is triggered, and so the table creation is not visible. Which is fascinating as it points the finger entirely at the updater!
I’d also really like to get out of maintenance mode and see if I still have a working 22 instance. Alas I can’t find how. Some on-line advice suggests the maintenance setting in config.php, but that already reads:
Sadly backups are still sporadic and on the agenda to make routine. It’s not a heavy production box, just a personal one and shared with a club, but it’s hosted on an Intel NUC if you’re really curious. Backups while important (I’m not blind or stupid) are just a priority among many (and I love the idea of P2P backup in 23) and has been procrastinated simply because a) upgrades have been reliable for a long time and quite trustworthy and b) Well the only things the instance really offers is Files and Contacts and Bookmarks and I have local versions of all of them and can if I must, rebuild a Nextcloud server and start fresh - In other words there’s no real data threat simply workload impacts and frustration.
I’m not sure though how any of that helps either a) escaping the upgrade effort - backing back down to see if the 22 instance is still functional or b) fixing this broken updater or the problem it has. I’d be keen to do a) then b) really.
A pointer to any docs on how the update process works would save me a lot of reverse engineering hassle (wading through PHP to find why it’s presenting the Upgrade page and not the login or Dashboard or whatever for example).
selfhosted? great. I just wanted to make sure that it wasn’t hosted on a shared service (which might lead to strange problems sometimes)
PS: you might wanna try the manual update by downloading the original file from download.nextcloud.com and then install that using bash (manual will tell you how doing that)
Thanks for the tip! I’be not tried those - in fact occ was broken and I had to enable acp in php.ini to get it going again - no idea when that broke, but it’s going now again.
I’ll try those two, but can’t do that for the next 8 or so hours (no access). I’m nervous as, I noted, tables referred to in the postgresql log don’t exist suggesting the upgrade is creating them. Still if there are premises about indices and columns the upgrader has that do not hold true on my instance maybe adding any missing ones will help.
Alas I had ssh access to the box from here, but a recent IP change here (in the move to IPv6) has killed that (as in there’s no way I’d keep an ssh port open to the world, it’s like a magnet for endless bot login efforts so I have it open only to select source IPs that I know I’m likely to work from).
And I’ can try a manual update yes. This is the procedure I expect you’re referring to:
I ran into this same error upgrade was attempted through the command line, I ran the db:add-missing-indices and db:add-missing-columns commands but they didn’t help I have been searching trying to find the SQL definition for the oc_profile_config table in attempt to add it manually so the script could attempt to continue but I haven’t been able to find the table schema information.
@SysKeeper I had already found that bug list, think comments there are headed in the right direction. anyway to restore operations of existing system without a restore from backup? I do have one, but original poster on this doesn’t appear to have a good backup.
Yep, no convenient backup to restore alas. I’m glad there’s a bug on github, I considered filing one but opted for here instead ;-). @dweimer if you find a solution/workaround do post it. I can’t look at it more closely till tonight alas no access to system. But have a plan of course, the manual upgrade path … we shall see.
Sooo… I also just got this error. Sadly found this post only after I solved the issue for myself.
But to add this here: The problem for me (and probably for some/most of you) was that the pico cms addon added a realtion (probably an index, but definitly not an unique index) called “user_id”. As in postgres and probably also mysql indexes mus have a database-wide unique name, the unique index that NC tries to create, can’t be.
I will create an issue with the addon. The frustrating part for me is: I don’t even use pico cms anymore.
