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

[MyrinNew]

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







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/







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







Example output:






uid=101(mongodb) gid=65534(nogroup)







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







Apply ACL:






sudo setfacl -m u:101:rwx /data/mongodb







Ensure ACL is inherited for newly created files:






sudo setfacl -d -m u:101:rwx /data/mongodb







Verify:






getfacl /data/mongodb







You should see entries like:






user:101:rwx
default:user:101:rwx







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







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







🔥 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.




More...