While upgrading from VMware App Volumes 2.18.1 to 2.18.10.10 version, the upgrade installer completes successfully. However, when you load the App Volumes Manager portal, you get the following error message – Startup Failure – Unable to start App Volumes Manager – Migrations are pending. To resolve this issue, run bin/rails db:migrate RAILS_ENV=production

Cause
Upon quickly checking the App Volumes computer account (<Domain>\<MachineName>$ within SQL Server was missing the db_onwer permissions. Obviously, that caused the above error post-migration.
Note – This is a very corner case and not expected to see along on most of the App Volumes Migration/Upgrade scenarios. If you did come across one now you know how to remediate.
Resolution
Step 1 – Adding the missing db_owner permission back to the App Volumes Manager computer security account within SQL Server Management Studio

Step 2 – As the db:migration didn’t complete during the upgrade, we need to re-run the following command on the App Volumes Manager server. Open the CMD and change directory to the following path – C:\Program Files (x86)\CloudVolumes\Manager\ruby\bin and run the following command:
bundle exec rake db:migrate RAILS_ENV=production
You should see the following output:

Step 3 – Restart the App Volumes Manager service, and now you will see the login page of the App Volumes Manager.
The mystery remains how did that permission go missing as the additional App Volumes Manager account had retained the db_owner role. But none the less the above steps came in handy with help from VMware support – Suman Rout luckily, has seen a similar issue before.
Lesson Learnt
- Create a pre-upgrade task item on checking to making sure all the App Volumes Manager computer accounts within the SQL Server have the db_owner permissions.
I hope you will find these steps helpful to resolve missing SQL permissions causing upgrade issues during the App Volumes migration from 2.18.x to 2.18.10.10.
Thanks,
Aresh Sarkari
Thank you for this! We were upgrading from 4.6.0 to 4.7.0 (2206) and experienced the same error. In our case, the DB user was set as DBO for the database, so we just needed to run the step 2 command, restart the service, and it fixed it.
Thanks for details mate! Great to hear we are not alone π