Scale up as you grow — whether you're running one virtual machine or ten thousand.

From GPU-powered inference and Kubernetes to managed databases and storage, get everything you need to build, scale, and deploy intelligent applications.

This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.
Hello,
Just came across this answer and decided to write some general guidelines for anyone who comes across this in the future despite the old question.
Firstly, I’m sorry to hear about the troubles you’re having, let’s try to get your MongoDB back up and running.
From the log, it appears that MongoDB is indeed running into a permission issue when it tries to access the file /mongo-metadata/WiredTiger.turtle.
Assuming MongoDB is running under the user ‘mongodb’, try running the following commands:
sudo chown -R mongodb:mongodb /mongo-metadata/
sudo chmod -R 755 /mongo-metadata/
These commands ensure that the MongoDB user has the appropriate permissions on the /mongo-metadata/ directory.
The chown command changes the owner of the directory (and all subdirectories and files, because of the -R flag for recursive) to the ‘mongodb’ user and group.
The chmod command changes the permissions of the directory (and all subdirectories and files) to 755. In Linux permission model, 755 means the owner (which now is ‘mongodb’) can read, write and execute, while the group and others can read and execute.
After running these commands, try restarting the MongoDB service again and see if it starts as normal.
In the event that you are still experiencing issues after changing the permissions, another possibility is that the abrupt shutdown caused some corruption to the MongoDB data files. MongoDB uses the WiredTiger storage engine, which generally recovers well from unclean shutdowns, but it’s not perfect.
If changing permissions doesn’t work, you may have to restore from a backup. If you don’t have a backup, you might try to repair the MongoDB, but be aware that this operation can result in data loss.
Also after fixing the permissions, try to attempt another repair as you did earlier by using the --repair option when starting MongoDB. You should make a backup of your data directory first, just in case.
I hope this information helps anyone who comes across this in the future.
A good option to consider is using a managed MongoDB service so that you don’t have to worry about managing such incidents:
Best,
Bobby