Running Chrome/Chromedriver inside Docker containers has become increasingly common for testing environments, but recent Docker version changes have introduced namespace-related challenges. The key symptom manifests when Chrome attempts to create new namespaces using the setns() system call:

Failed to move to new namespace: PID namespaces supported,
  Network namespace supported,
  but failed: errno = Operation not permitted
Aborted (core dumped)

The behavior change occurs between Docker versions:

• Working version: Docker 1.11.2 (CoreOS 1185.5.0)
• Breaking version: Docker 1.12.3 (CoreOS 1235.4.0)

The root cause traces to Docker's enhanced security restrictions in newer versions regarding namespace operations.

Two approaches can resolve the namespace creation issue:

# Solution 1: Add specific capability
docker run --cap-add=SYS_ADMIN your_chrome_container

# Solution 2: Use privileged mode (NOT recommended)
docker run --privileged your_chrome_container

The key differences between these approaches:

The SYS_ADMIN capability specifically allows:

• Namespace creation/modification (setns(), unshare())
• Mount operations
• Other administrative functions

For security-conscious deployments, use the minimal required capability combination:

docker run \
  --cap-add=SYS_ADMIN \
  --cap-add=SYS_CHROOT \
  --security-opt seccomp=unconfined \
  -e DISPLAY=$DISPLAY \
  -v /tmp/.X11-unix:/tmp/.X11-unix \
  your_chrome_image

For environments where capabilities can't be modified:

# Disable sandboxing (security trade-off)
chrome --no-sandbox

# Use headless mode (preferred for testing)
chrome --headless --disable-gpu

When granting SYS_ADMIN:

• Isolate containers using user namespaces (--userns=host)
• Implement resource limits (--memory, --cpus)
• Consider read-only filesystems where possible

To diagnose namespace-related problems:

# Check available namespaces
ls -l /proc/$$/ns/

# Verify capabilities
capsh --print

# Test namespace operations
unshare --user --map-root-user

When running Chrome/Chromedriver inside Docker containers, recent CoreOS updates (specifically Docker 1.12.3) introduce namespace-related failures that weren't present in Docker 1.11.2. The key error message reveals the problem:

Failed to move to new namespace: PID namespaces supported,
  Network namespace supported,
  but failed: errno = Operation not permitted
Aborted (core dumped)

Chrome uses Linux namespaces as part of its sandboxing mechanism. The setns() system call, which Chrome relies on for creating namespaces, requires specific capabilities in newer Docker versions.

Both solutions work but have different security implications:

# Option 1: Privileged mode (full system access)
docker run --privileged my_chrome_container

# Option 2: Specific capability addition
docker run --cap-add=SYS_ADMIN my_chrome_container

The --privileged flag grants all capabilities to the container, effectively removing all isolation boundaries. In contrast, --cap-add=SYS_ADMIN only adds the specific capability needed for namespace operations.

For most use cases, the minimal capability addition is preferable. Here's a complete Docker command example:

docker run -d \
  --cap-add=SYS_ADMIN \
  -e DISPLAY=$DISPLAY \
  -v /tmp/.X11-unix:/tmp/.X11-unix \
  chrome-test:latest

For environments where even SYS_ADMIN is too permissive, consider:

• Using Chrome's --no-sandbox flag (not recommended for production)
• Running Chrome in headless mode with different security requirements
• Implementing seccomp profiles to whitelist only required syscalls

The behavior differs between Docker versions: