It's a year of curious learning for me and this involves encountering bugs and even recreating them just so I learn from them.
I started a deep dive into mongoDB this month so that I fully understand how to use the tool. I ran into this issue and I spent over three hours trying to fix it.
NOTE: The cause of the error was starting my mongo service with the sudo command which I advise against because it exposes your system to unnecessary risks if mongoDB is compromised. For your case, it could be something else.
I didn't find any useful resource on forums or blogs. But with help from ChatGPT and the official docs, I was able to come to a solution.
Objectives
At the end of this article, you'll have learned:
- how to solve the mongodb-community error 3584
- how to read mongodb logs from the terminal
- how to use terminal commands to change permissions
- how to troubleshoot errors
Prerequisites
- Apple Silicon chip Mac
- Homebrew package manager
- MongoDB Community edition
TL;DR
This article is intended to be a deep dive but if you're in a hurry, reference this.
NOTE: This solution will only work if you've used the sudo command to start the mongod background service at any time.
- Check logs to see errors.
cat /opt/homebrew/var/log/mongodb/mongo.log
If you see any "Permission denied" error message, proceed with this solution.
- Restore the permissions to the non-root user:
sudo chown -R $(whoami):admin /opt/homebrew/Cellar/mongodb-community
sudo chown -R $(whoami):admin /opt/homebrew/opt/mongodb-community
sudo chown -R $(whoami):admin /opt/homebrew/var/homebrew/linked/mongodb-community
sudo chown -R $(whoami):admin /opt/homebrew/var/mongodb
- Verify that the non-root user now has permissions for the previously affected files
ls -ld /opt/homebrew/var/mongodb
ls -l /opt/homebrew/var/mongodb
- Restart the mongod background services
brew services restart mongodb-community
- Start up the mongo shell
mongosh
The deep dive into solving the error.
sudo brew services start mongodb-community@8.0
I attempted to run the mongod background service using the sudo command because I saw the instructor do same in the video resource I am using (rookie mistake🥲). This was what led me down the rabbit hole of solving this error.
The command was successful but I got a soft warning that the permissions and ownership of some folders and files have changed.
I should have known something was going to go wrong from that point but hey, curious learning, right?.
I switched my terminal tab and attempted to run the mongosh command to start up the mongo shell but I got a network connection error.
I didn't change the port, so why the error? Time to troubleshoot🛠️.
Troubleshooting
Using a brew command, I first checked the services list to see if the service was running.
brew services list
The service was running but with an error. No error message provided. So what do I work with?
In a previous video, the instructor talked about the mongodb logs that is created on my local machine. It logs out entries of different actions so it should definitely tell what happened.
In the docs, the path to the logs was specified as /opt/homebrew/var/log/mongodb so I read the log file using the cat command.
cat /opt/homebrew/var/log/mongodb/mongo.log
-> Running this command will print out the existing logs to the terminal but the downside is that it's not prettified.
However, with a little patience and eyes squinting, I was able to find the log for the start of the service.
-> The object can only contain these keys:
{
"t": <Datetime>, // timestamp of the log message in ISO-8601 format
"s": <String>, // Short severity code of the log message
"c": <String>, // Full component string for the log message
"id": <Integer>, // Unique identifier for the log statement.
"ctx": <String>, // Name of the thread that caused the log statement.
"svc": <String>, //
Name of the service in whose context the log statement was made.
"msg": <String>, // message body of the log
"attr": <Object>, // additional attributes (optional)
"tags": <Array of strings>, // tags (optional)
"truncated": <Object>, // truncation info (if truncated)
"size": <Object> // original size of entry (if truncated)
}
To read more about logs, check out the docs
I copied the most recent logs and used chatGPT to prettify it to JSON.
{
"t": { "$date": "2025-01-19T13:10:07.261+01:00" },
"s": "E",
"c": "WT",
"id": 22435,
"ctx": "initandlisten",
"msg": "WiredTiger error message",
"attr": {
"error": 13,
"message": "[1737288607:261307][2013:0x1f722f840], wiredtiger_open: [WT_VERB_DEFAULT][ERROR]: int __posix_open_file(WT_FILE_SYSTEM *, WT_SESSION *, const char *, WT_FS_OPEN_FILE_TYPE, uint32_t, WT_FILE_HANDLE **), 928: /opt/homebrew/var/mongodb/WiredTiger.turtle: handle-open: open: Permission denied"
}
}
{
"t": { "$date": "2025-01-19T13:10:07.261+01:00" },
"s": "W",
"c": "STORAGE",
"id": 22347,
"ctx": "initandlisten",
"msg": "Failed to start up WiredTiger under any compatibility version. This may be due to an unsupported upgrade or downgrade."
}
{
"t": { "$date": "2025-01-19T13:10:07.261+01:00" },
"s": "F",
"c": "STORAGE",
"id": 28595,
"ctx": "initandlisten",
"msg": "Terminating.",
"attr": { "reason": "13: Permission denied" }
}
{
"t": { "$date": "2025-01-19T13:10:07.261+01:00" },
"s": "F",
"c": "ASSERT",
"id": 23091,
"ctx": "initandlisten",
"msg": "Fatal assertion",
"attr": {
"msgid": 28595,
"file": "src/mongo/db/storage/wiredtiger/wiredtiger_kv_engine.cpp",
"line": 761
}
}
{
"t": { "$date": "2025-01-19T13:10:07.261+01:00" },
"s": "F",
"c": "ASSERT",
"id": 23092,
"ctx": "initandlisten",
"msg": "\n\n***aborting after fassert() failure\n\n"
}
The focus of this result would be the "Permission denied" errors. I was currently running the process in sudo mode which should give me access to the current files I was trying to access but it was still failing for some reason.
So I troubleshooted further by checking the permissions on the files responsible for running the mongod background service.
I asked ChatGPT for a command that could help me do this. These were the suggested commands
ls -ld /opt/homebrew/var/mongodb
ls -l /opt/homebrew/var/mongodb
To understand what each line does, let me break it down for you.
-> ls -ld - Displays detailed information about the specified directory, but not its contents.
Output
drwxr-xr-x 10 username group 320 Jan 13 12:00 path
- d: Indicates it is a directory.
- rwxr-xr-x: Permissions (owner has read/write/execute, group and others have read/execute).
- 10: Number of links (subdirectories or files).
- username: Owner of the directory.
- group: Group that owns the directory.
- 320: Size of the directory in bytes.
- Jan 13 12:00: Last modification date and time.
-> ls -l - Displays detailed information about the contents of the specified directory.
Output
-rw------- 1 username group 1024 Jan 13 12:00 WiredTiger.turtle
-rw------- 1 username group 40960 Jan 13 12:00 WiredTiger.wt
drwx------ 3 username group 128 Jan 13 12:00 journal
- -rw-------: File permissions (read/write for owner, no access for group or others).
- 1: Number of links (for files, this is usually 1).
- username: Owner of the file or directory.
- group: Group that owns the file or directory.
- 1024: Size of the file in bytes.
- Jan 13 12:00: Last modification date and time.
- WiredTiger.turtle: Name of the file.
Looking at the output, I noticed something different. The files and folders were registered to my root user but the service is recommended to be used with the non-root user (the current user profile).
So to restore back ownership and permissions to the non-root user, I had to use the sudo command on the files that I was warned about.
sudo chown -R $(whoami):admin /opt/homebrew/Cellar/mongodb-community
sudo chown -R $(whoami):admin /opt/homebrew/opt/mongodb-community
sudo chown -R $(whoami):admin /opt/homebrew/var/homebrew/linked/mongodb-community
-
chown: change ownership - -R: runs the command recursively on content of the specified folder
- whoami: this is a command that returns your username
- admin: this is a group that has been created on your laptop
The files were restored and I ran the mongosh command again. Should work now, right? Nope!
Still had the permissions error again even after I had restored ownership to the files. So I went back to the logs.
I still saw the "Permission denied" error and after careful analysis of the log object, I noticed the file which was causing the issue was WiredTiger.turtle which meant that I haven't transferred ownership back to the file.
Using the ls command again, I found that the file still belonged to the root user.
I ran the chown command on the directory of the file.
sudo chown -R $(whoami):admin /opt/homebrew/var/mongodb
I ran the ls command again to check if the ownership has been changed, and alas, it was.
Just to be sure, I had to restart the mongod service and when the service started up I ran the mongosh command with my fingers crossed and voila, it was successful.
Conclusion
Errors like these are exciting because they teach you to be resourceful and find solutions in the deepest places of the internet.
After spending over three hours searching different forums on the internet trying to find a solution, the solutions I found were either for Intel macs or resorting to use MongoDB Compass (a GUI for accessing your database).
The fastest way to grow is to break stuff so you can fix them and that's what I'll be doing most of the year. I hope I've been able to teach you all that I promised you'll learn from reading this article.
Please drop a comment if you have other ways you've solved this.
See you in my next adventure.
Top comments (0)