I updated to 2026.3.0 using the updateself and update yesterday and my MSSQL container seems to be stuck and full of this error:
Login failed for user ‘sa’. Reason: Server is in script upgrade mode. Only administrator can connect at this time.
This has been running without issue for several years and I am not sure how to best approach the problem.
Note: I managed to roll back to 2026.2.1 and everything seems to be fine but I will need to update at some point.
assuming they are talking about going to <bitwarden.domain.com>/admin that actually resulted in a 502 bad gateway error when I was having the problem.
It looks like everything but MSSQL is working correctly.
Hi;
Same problem after 2026.3.0 update. Hosting on Synology DSM 7.3.2. Bitwarden-mssql logs:
”Login failed for user ‘sa’. Reason: Server is in script upgrade mode. Only administrator can connect at this time.”
Then it crashers:
”This program has encountered a fatal error and cannot continue running at…”
Restarting and the loop starts all over again.
I have exactly the same issue. I’m also hosting on Synology DSM 7.3.2. When MSSQL starts it attempts to update the database using script repl_upgrade.sql and then eventually crashes. It then just restarts and does the same thing again.
I see a message like this is in the log:
2026-03-22 13:07:16.18 Server Process 0:0:0 (0x260) Worker 0x0000000F06BAE180 appears to be non-yielding on Scheduler 3. Thread creation time: 13418658353746. Approx Thread CPU Used: kernel 52980 ms, user 13390 ms. Process Utilization 24%. System Idle 0%. Interval: 70010 ms.
and then:
What steps did you take to rollback to 2026.2.1?
The only thing I found that might be relevant (or not): what MSSQL version are all using? The BW Help Sites show this note:
I would recommend to also contact BW support. Maybe they can help with this.
It’s a Docker setup with the official MSSQL image from Bitwarden; it should be 100% compatible.
I also tried waiting longer after the update (the script has a built-in sleep for 60 seconds, but MSSQL crashes the same way even if it’s longer and no other connections are made).
Rollback is not recommended, but what I did was:
Ah, seems @nickjossy reported this as a potential bug now:
I am also hosting on Synology (DS1621+) running DSM 7.3.2.
I did some research before rolling back, and it is risky rolling back databases to older versions (stop bitwarden before doing this). I restored my files to the previous day to ensure my stuff would be ok before doing it.
Inside bitwarden.sh line 67-70, change the COREVERSION and WEBVERSION to the 2026.2.1 which is the previous version.
# Please do not create pull requests modifying the version numbers.
COREVERSION=“2026.2.1”
WEBVERSION=“2026.2.1”
KEYCONNECTORVERSION=“2025.11.0”
After that, update docker-compose.yml all images to version 2026.2.1.
I then did a bitwarden.sh stop, then bitwarden.sh rebuild and then a bitwarden.sh start.
https://bitwarden.com/help/install-on-premise-linux/#script-commands-reference
@Nail1684 the issue does appear to be the same one you linked too on GitHub.
also getting this error.
I have rollback my docker dwdata folder to just before the update and re-run the update using the old version.
I have re-create the raw.githubusercontent.com/lizardkingdotca/bitwarden_public/refs/heads/main/bitwarden.sh
with the following value
# Please do not create pull requests modifying the version numbers.
COREVERSION="2026.2.1"
WEBVERSION="2026.2.1"
KEYCONNECTORVERSION="2025.11.0"
you can after download run the command to rollback to 2026.2.1
./bitwarden.sh update
Same for me on Synology DSM 7.2.1-69057 Update 11
It also seems to affect the SSO and Admin containers.
Their logs hint that they are struggling to connect to the database container on my setup.
So you modified the updater script with old version numbers and it effectively performed the rollback for you? Or did you have to interfere with the git side of things as well?
This is how I rolled back.
Having reviewed the logs I could see that when MSSQL starts it attempts to upgrade the DB. This always failed and the database did a rollback each time. On that basis I felt it was probably safe to rollback to 2026.2.1 without doing any form of DB restoration.
I had multiple backups of my database and docker folders that I could make use of if this didn’t work.
I stopped everything (./bitwarden.sh stop), copied the existing Bitwarden.sh (cp Bitwarden.sh bitwarden2.sh), edited Bitwarden2.sh and changed both COREVERSION and WEBVERSION to 2026.2.1
I then ran ./bitwarden2.sh update
Everything is now working fine.
I’ve temporarily disabled my scheduled update script until I’m satisfied this issue is fixed.
Just a little concerned that I may now be running an instance with vulnerabilities, so hopefully they’ll sort things out soon 
Worked well for me too. I figure the next update will resolve this with the updateself correcting any changes made to the install script.
I encountered the same issue on my self-hosted system on Synology. Rolling back to 2026.2.1 per the instructions others have provided solved my issue as well.
Hi everyone, thanks for the detailed info! After looking at your Docker releases, it looks like engine 24.0.2 is a couple years old (and doesn’t provide support for cgroup v2, which Bitwarden requires).
Can you check to see if there are any updates available?
Don’t think it’s docker problem. Synology uses LTS version. Docker/container runs fine, MySQL is logging unaccessible because it’s in update mode. Nothing to do with docker layer.
I’m running Bitwarden Self Hosted on the Synology Docker 24.0.2 version and it’s running fine, no issues. I do however use postgres for my database.