DEV Community

Ragul
Ragul

Posted on

🚀 Deploying MongoDB on Docker with Secure Host Directory Mounts Using ACLs (Without Changing Permissions)

#mongodb #docker #containers #linux

When running production containers, it’s common (and recommended) to restrict Docker access to a dedicated Linux user. This user can run Docker commands but cannot modify system-wide permissions on host directories.

However, this leads to a classic problem:

A Docker user cannot modify file permissions, and MongoDB cannot read/write the mounted directory because the directory is 755.

MongoDB inside a container usually runs as a non-root UID, and with directory permissions 755, only the owner can write.
So how do you allow MongoDB inside the container to read/write the directory without changing default permissions like chown or chmod on the host?

The answer: Use Linux ACL (Access Control Lists).

This guide walks through how ACL solves real-world permission challenges securely.

✅ 1. Why Directory Permission Becomes a Problem
A typical MongoDB Docker deployment mounts a host directory:

docker run --name mongodb -d -p 27017:27017 -v /data/mongodb:/data/db mongodb/mongodb-community-server
Enter fullscreen mode Exit fullscreen mode

But if /data/mongodb has permission 755:

  • Only the owner can write.
  • MongoDB inside the container runs as a non-root user (e.g., UID 101 or 999).
  • It cannot write → MongoDB fails to start. And since your Docker admin account cannot use sudo or change ownership, you cannot do: 
chown -R mongodb:mongodb /data/mongodb/
chmod 777 /data/mongodb/
Enter fullscreen mode Exit fullscreen mode

Both are insecure anyway.

So how do we give write access without touching permissions?

👉 Use ACL.

✅ 2. Find the Real UID of MongoDB Inside Your Running Container
Run:

docker exec mongodb id
Enter fullscreen mode Exit fullscreen mode

Example output:

uid=101(mongodb) gid=65534(nogroup)
Enter fullscreen mode Exit fullscreen mode

So MongoDB actually runs as UID 101.

That’s the UID we need to give access to.

✅ 3. Use ACL to Give MongoDB Read/Write Access (Without Changing 755 Permissions)
Let’s say your host directory is:

/data/mongodb
Enter fullscreen mode Exit fullscreen mode

Apply ACL:

sudo setfacl -m u:101:rwx /data/mongodb
Enter fullscreen mode Exit fullscreen mode

Ensure ACL is inherited for newly created files:

sudo setfacl -d -m u:101:rwx /data/mongodb
Enter fullscreen mode Exit fullscreen mode

Verify:

getfacl /data/mongodb
Enter fullscreen mode Exit fullscreen mode

You should see entries like:

user:101:rwx
default:user:101:rwx
Enter fullscreen mode Exit fullscreen mode

No chmod. No chown. No permission changes.
Secure, clean, production-safe. ✔️

✅ 4. Mount the Directory Normally in Docker
Now your dedicated Docker user can run:

docker run --name mongodb -d -p 27017:27017 -v /data/mongodb:/data/db mongodb/mongodb-community-server
Enter fullscreen mode Exit fullscreen mode

MongoDB starts successfully because:

  • The directory stays 755
  • ACL gives UID 101 full access

✅ 5. Why ACL Is the Best Approach in This Setup

✔ Does not change directory ownership
You avoid breaking other system dependencies.

✔ Does not weaken permissions
755 remains intact — no risky 777.

✔ Works with any container UID
MongoDB, Postgres, MySQL, Redis — all run as non-root users.

✔ Works perfectly when Docker is managed by a restricted user
Your Docker admin user cannot modify filesystem permissions, but can apply ACL (if allowed).

✔ Clean and reversible
To remove ACL:

setfacl -b /data/mongodb
Enter fullscreen mode Exit fullscreen mode

🔥 Final Takeaway

Running MongoDB in Docker with a non-root host user often leads to mount permission issues.
Instead of loosening permissions or changing directory ownership, you can solve it professionally using ACL:

  1. Check MongoDB UID inside the running container.
  2. Apply ACL on the host folder for that UID.
  3. Mount the directory normally.
  4. MongoDB runs smoothly, safely, and without permission hacks.

This is the cleanest, most production-friendly approach — especially in environments where Docker is managed by dedicated restricted users.

Top comments (0)