Analysis and Solutions for Permission Denied Issues When Non-root Users Create Directories in Docker Containers

Problem Background and Phenomenon Analysis

During Docker container builds, permission denied errors frequently occur when non-root users attempt to create system-level directories. This phenomenon fundamentally stems from Docker's filesystem permission mechanisms, which remain consistent with traditional Linux systems.

In the specific example scenario, after executing the USER newuser directive, all subsequent RUN commands execute under the newuser identity. When attempting to create the /newfolder directory under the root directory, the operation fails because the root directory's default permissions are set to dr-xr-xr-x (i.e., 755 permissions), where only the root user possesses write privileges, thereby preventing non-root users from creating new directories or files in this location.

In-depth Analysis of Permission Mechanisms

Filesystem permissions within Docker containers inherit from the base image. In mainstream Linux distributions like Ubuntu, the root directory ownership belongs to the root user with 755 permissions configured. This means:

• The root user has full read, write, and execute privileges
• Other users only have read and execute privileges, unable to perform write operations

sudo privilege configuration doesn't take effect in this scenario because RUN commands during Docker builds execute in non-interactive mode by default, preventing sudo's password verification process from triggering. Even if users are added to the sudoers group, privilege escalation via sudo remains unavailable during the build phase.

Best Practice Solutions

Based on understanding permission mechanisms, the recommended solution involves completing directory creation and permission configuration under root privileges before switching to the target user. Specific implementation is as follows:

FROM ubuntu:16.04

RUN apt-get update && \
    apt-get -y install sudo

RUN adduser --disabled-password --gecos '' newuser \
    && adduser newuser sudo \
    && echo '%sudo ALL=(ALL:ALL) ALL' >> /etc/sudoers

RUN mkdir -p /newfolder
RUN chown newuser:newuser /newfolder
USER newuser
WORKDIR /newfolder

The core advantages of this solution include:

1. Creating target directories under root privileges to ensure operation success
2. Using the chown command to transfer directory ownership to the target user
3. Switching to the target user context after permission configuration completes
4. Maintaining Docker image security and the principle of least privilege

Related Technical Extensions

Similar permission issues frequently appear in other Docker application scenarios. For example, in Solr-based image builds, the same pattern can be adopted:

FROM solr:8
USER root
RUN mkdir /searchVolume
RUN chown solr:solr /searchVolume
USER solr

This approach ensures dedicated users have full control over their working directories while adhering to Docker security best practices. In actual production environments, considerations should also include refined directory permission control, appropriate umask settings, and potential SELinux or AppArmor policy configurations.

Security Considerations and Best Practices

When handling permission issues during Docker image builds, balancing functional requirements with security needs is essential:

• Avoid running application services with root privileges within containers whenever possible
• Reasonably set file and directory permissions following the principle of least privilege
• Consider using Docker's user namespace functionality to enhance isolation
• Regularly audit permission configurations in images to ensure compliance with security standards

Through proper permission management and user switching strategies, secure and fully functional Docker images can be constructed, providing a solid foundation for stable operation of containerized applications.