Resolving MongoDB Permission Errors on EC2 with EBS Volume: Unable to create/open lock file

Problem Background and Error Analysis

When deploying MongoDB on AWS EC2 instances, developers often need to configure the data directory to use mounted EBS storage volumes. However, the common permission error Unable to create/open lock file: /data/mongod.lock errno:13 Permission denied frequently causes service startup failures. The error code errno:13 clearly indicates insufficient permissions, but the specific causes require deep analysis of filesystem permissions and MongoDB runtime environment.

Root Cause Diagnosis

By examining system logs and directory structures, the core issue is identified as the MongoDB process being unable to create necessary lock files in the specified data directory. In Ubuntu systems, the MongoDB service typically runs under the mongodb user identity, while newly mounted EBS volume directories default to belonging to the root user, creating a permission mismatch.

When checking directory permissions using ls -la command:

drwxr-xr-x  4 root root  4096 Mar  5 16:28 data
drwxr-xr-x  2 root root  4096 Mar  5 16:28 db

This shows that the /data/db directory owner and group are both root, while the MongoDB process needs to write to this directory as the mongodb user.

Complete Solution Steps

Based on high-scoring Stack Overflow answers and practical verification, here are the systematic steps to resolve this issue:

Stop Existing Service

First ensure no running MongoDB instances:

sudo service mongodb stop

Check and Set Correct Directory Permissions

Reference the permission configuration of existing working directory:

ls -la /var/lib/mongodb

The output typically shows the directory belongs to mongodb:mongodb. Apply the same permissions to the new data directory:

sudo chown -R mongodb:mongodb /data/db

This command recursively changes the owner and group of the /data/db directory and all its contents to mongodb.

Update MongoDB Configuration

Edit the MongoDB configuration file:

sudo nano /etc/mongodb.conf

Locate the dbpath configuration item and modify it to:

dbpath = /data/db

Clean Old Data Files (Optional)

If the contents of the original data directory are no longer needed, clean them:

sudo rm -rf /var/lib/mongodb/*

Restart Service and Verify

Start the MongoDB service:

sudo service mongodb start

Wait approximately 60 seconds for the service to fully initialize, then check the new data directory:

ls -la /data/db

You should see necessary files created by MongoDB, including:

• mongod.lock - Process lock file
• journal/ - Journal directory
• local.ns, local.0 - Database files

In-depth Analysis of Permission Management Principles

The Linux filesystem permission model is based on three entities: user, group, and others. The MongoDB process requires during startup:

• Read permission (r) on the data directory to check existing files
• Write permission (w) on the data directory to create new files and lock files
• Execute permission (x) on the data directory to access directory contents

The command chown -R mongodb:mongodb /data/db ensures:

• The directory owner becomes the mongodb user
• The directory group becomes the mongodb group
• Due to owner matching, the MongoDB process obtains full read-write-execute permissions

Alternative Solution References

Other viable solutions include adjusting directory permission modes:

sudo chmod 0755 /data/db
sudo chown -R $USER /data/db

This approach is suitable for development environments where developers run MongoDB directly under their personal user accounts. However, in production environments, using the dedicated mongodb user is more secure.

Preventive Measures and Best Practices

To avoid similar issues, it is recommended to:

• Set correct directory permissions immediately after mounting EBS volumes
• Use automated scripts to configure MongoDB environments
• Regularly check service logs to catch permission-related issues
• Verify permission configurations remain unchanged after system upgrades

Conclusion

Permission errors when using MongoDB with EBS storage volumes on EC2 are common but easily resolvable issues. By properly setting directory ownership and permissions, updating configuration files, and following systematic verification processes, developers can ensure stable database service operation. Understanding the Linux permission model and MongoDB runtime requirements is key to preventing and resolving such problems.