Debugging volume mount issues in Docker - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

Volume mount path error output

What error message will Docker show if you try to mount a host directory that does not exist?

Docker

docker run -v /nonexistent/path:/app busybox ls /app

A Error: No such container: /nonexistent/path

B ls: cannot access '/app': No such file or directory

C Error response from daemon: invalid mount config for type "bind": bind source path does not exist: /nonexistent/path

D Permission denied while accessing /nonexistent/path

💡 Hint

Docker checks if the host path exists before starting the container.

Docker requires the host directory to exist before mounting it. If it doesn't, Docker shows an error about invalid mount config and missing source path.

❓ Troubleshoot

intermediate

Container cannot write to mounted volume

You mounted a host directory into a container, but the container process cannot write files inside it. What is the most likely cause?

A The host directory has read-only permissions for the container user

B The container image does not have write permissions on /bin

C Docker daemon is running in rootless mode

D The container network is disconnected

💡 Hint

Check the permissions of the host directory and the user inside the container.

If the host directory is owned by root and has no write permission for others, the container user cannot write to it. This is a common cause of write failures.

❓ Configuration

advanced

Correct volume mount syntax in docker-compose

Which docker-compose volume syntax correctly mounts the host directory /data into /app/data inside the container with read-write access?

A

volumes:
  - /data:/app/data:rw

B

volumes:
  - /data:/app/data

C

volumes:
  - /app/data:/data

D

volumes:
  - /data:/app/data:ro

💡 Hint

By default, volume mounts are read-write unless specified otherwise.

The syntax '/data:/app/data' mounts the host /data directory into the container path /app/data with read-write access by default. Adding ':rw' is optional but valid.

✅ Best Practice

advanced

Avoiding permission issues with Docker volumes

What is the best practice to avoid permission problems when mounting host directories into Docker containers?

A Disable SELinux or AppArmor on the host

B Run the container as root user to bypass permission checks

C Always mount host directories as read-only

D Use named Docker volumes instead of host directory mounts

💡 Hint

Consider Docker-managed storage to avoid host permission conflicts.

Named Docker volumes are managed by Docker and avoid host permission issues because Docker controls the volume's ownership and permissions. This is a best practice for consistent behavior.

🧠 Conceptual

expert

Understanding volume mount propagation modes

Which volume mount propagation mode allows changes in the container's mounted volume to be reflected back to the host and other containers?

A rshared

B rprivate

C rslave

D private

💡 Hint

Propagation modes control how mount events propagate between host and container.

The 'rshared' propagation mode allows mount and unmount events to propagate both ways between the host and container, enabling changes in the container to be visible on the host and other containers.