You start with something simple:
Mount your project folder into a container to access your files.
β
It works! You can see all your files
Everything looks perfect... so why worry?
Navigating Shared Mounts and Rootless Containers
Ever seen this mysterious warning?
WARN[0000] "/" is not a shared mount, this could cause issues or missing mounts with rootless containers
Welcome to the fascinating world of Linux mount propagation, rootless containers, and the subtle dance between namespaces! This guide will take you on a journey through one of the more esoteric corners of container technology.
π Table of Contents
1. What is Mount Propagation? ποΈ
Mount propagation is a Linux kernel feature that controls how mount events flow between different mount namespaces. Think of it as the "gossip protocol" for filesystems.
The Three Propagation Modes
| Mode | Behavior | Use Case |
|---|---|---|
| shared | Mount events propagate bidirectionally between peer groups | When you want containers to see host mounts (and vice versa) |
| private | Mount events do not propagate at all | Complete isolation (default for security) |
| slave | Receives mount events from master, but doesn't send them back | One-way visibility (container sees host, host doesn't see container) |
Visual Example: How Propagation Works
Shared Mount
PROPAGATES
Host Namespace
/dev/sda1 β /data
Container Namespace
/data
VISIBLE
Mount events flow between namespaces
Private Mount
ISOLATED
Host Namespace
/dev/sda1 β /data
Container Namespace
Mount events stay isolated in host
Key Insight: Mount propagation is not about file permissions or access control. It's about whether mount/unmount events are visible across namespace boundaries.
# Check current propagation mode
findmnt -o TARGET,PROPAGATION /
# Output examples:
# TARGET PROPAGATION
# / shared β Mount events can propagate
# / private β Mount events stay isolated
2. Rootless Containers Explained π
Rootless containers are containers that run without requiring root privileges on the host system. This is a major security improvement over traditional container runtimes.
How Rootless Works
Traditional (Rootful) Container:
Rootless Container:
The Magic: User Namespaces
Rootless containers rely heavily on user namespaces, which allow UID/GID remapping:
- Inside the container: Process thinks it's running as root (UID 0)
- Outside the container: Process is actually your user (UID 1000)
- Result: Container can't actually harm the host even if compromised
Why This Matters for Mounts: Because rootless containers use user namespaces and mount namespaces together, they have limited ability to create mounts that the host can see. This is where mount propagation becomes critical.
3. Decoding the Warning β οΈ
The Warning Message:
WARN[0000] "/" is not a shared mount, this could cause issues or missing mounts with rootless containers
What Podman is Actually Saying
When Podman issues this warning, it's telling you:
- Current State: Your host's root filesystem (
/) has propagation mode set toprivate - Potential Problem: Bind mounts from the host into containers might not work as expected
- Specific Risk: Nested mounts (mounts under your bind-mounted directories) won't appear inside the container
The Bind Mount Problem
The Setup That Tricks Everyone
But Then Reality Hits
Container-in-Container
Your CI/CD pipeline tries to build a container image from inside the container and suddenly...
"failed to read dockerfile: no such file or directory"
The inner Docker can't see your mounted files properly!
Kubernetes Pods
Your pod needs to access host data, but when it tries to create additional mounts...
"operation not permitted"
Kubernetes can't work with your bind mount!
Development Tools
Your hot-reload dev server should detect file changes, but...
"inotify cannot watch"
File watching breaks with the wrong mount type!
Backup Tools
Your rsync backup should create efficient hard links, but fails with...
"Invalid cross-device link"
Hard links don't work across private mounts!
What's Actually Going On?
β οΈ Default Behavior
Private Mount
Files are visible but you can't do advanced operations
β
Fixed
Shared Mount
Everything works - all operations supported
The Simple Fix
Just add one flag to your mount command:
β Breaks with advanced tools
podman run -v /home/user/project:/work
β
Works with everything
podman run -v /home/user/project:/work:rshared
The :rshared flag tells Podman to share the mount properly, enabling all advanced operations.
Quick Guide: When to Use Which
Just Reading Files
Simple file access, basic scripts
Default works fine
Development Work
Hot reload, file watchers, dev servers
Use :rshared
Container Tools
Container-in-Container, Kubernetes, CI/CD
Use :rshared
Backup & Sync
rsync, hard links, advanced tools
Use :rshared
When Does This Actually Break?
Nested Mounts
You bind-mount directories that contain other mount points
mount --bind /home/user /workBut /home/user has /mnt/data mounted inside
Systemd Containers
You're running containers that expect to see systemd mounts
podman run --systemdContainer can't see host's systemd mount tree
FUSE Filesystems
You're using FUSE filesystems inside bind-mounted paths
sshfs user@server:/data /mnt/remoteContainer can't access the FUSE mount
Container-in-Container
You're doing Docker-in-Docker or Kubernetes-in-Docker scenarios
docker run -v /var/run/docker.sock:/var/run/docker.sockInner container can't see mounted volumes
WSL2 Windows Drives
You mount Windows drives into containers in WSL2
podman run -v /mnt/c:/workWindows drives appear as separate mount namespaces
Reality Check: For simple containers that just need to access files (not nested mounts), this warning is often harmless. Many developers run rootless Podman for years without ever hitting this issue.
4. The WSL2 Context πͺπ§
Why WSL2 Makes This More Common
WSL2 is not native Linuxβit's a lightweight virtual machine running a real Linux kernel, managed by Windows. This architecture has implications for mount propagation:
WSL2 Architecture Stack:
Windows Host
Physical machine with Windows OS
Hyper-V Hypervisor
Virtualization layer
WSL2 Linux VM
Your "host" for containers
Private mount propagation by default
Rootless Podman
Containers running inside VM
β οΈ Mount isolation issues
WSL2-Specific Mount Challenges
Root Filesystem
The
/ in WSL2 is typically mounted with private propagation by defaultThis is why you see the warning - WSL2's root isn't shared
Windows Drives
/mnt/c, /mnt/d etc. are special mounts using 9p/virtiofs protocolVirtual filesystem layer adds complexity to mount operations
Dynamic Mounts
WSL2 creates and destroys mounts dynamically based on Windows activity
Mounts appear/disappear as Windows accesses files
Permission Mapping
Windows NTFS permissions are translated to Linux permissions on-the-fly
Complex translation between Windows and Linux permission models
Common WSL2 + Rootless Container Pitfall
The Problem
Mounting
/mnt/c/Users/YourName/project into a container often fails or behaves strangelyComplex Propagation Rules
The
/mnt/c mount itself has complex propagation rulesPermission Mismatch
Windows file permissions don't map cleanly to Linux UIDs
Double Translation
The rootless container's UID mapping adds another layer of translation
The Solution
Keep your projects in the Linux filesystem when working with containers
Avoid This
/mnt/c/Users/YourName/project
Windows mount with complex translation
Use This Instead
/home/youruser/project
Native Linux filesystem, direct access
Better performance
Simpler permissions
No mount issues
Linux-native
Checking Your WSL2 Mount Propagation
# Check root propagation
findmnt -o TARGET,PROPAGATION /
# Check Windows mount propagation
findmnt -o TARGET,PROPAGATION /mnt/c
# See all mount propagation settings
findmnt -o TARGET,PROPAGATION | grep -E '(shared|private|slave)'
5. Security Implications π
Changing mount propagation from private to shared has security implications, though they're often modest for single-user development environments.
π Risk #1: Mount Visibility
With shared propagation, mount events created in one namespace can become visible in another. A malicious container with sufficient capabilities could potentially create mounts that affect the host.
Mitigation: Rootless containers have limited capabilities by default.
π Risk #2: Mount Injection
A compromised container might try to create confusing mount points that trick other processes or containers into accessing unexpected filesystems.
Mitigation: Requires CAP_SYS_ADMIN within the namespace, which rootless containers don't have over the host.
π Risk #3: Information Disclosure
Shared propagation could allow a container to observe mount/unmount events on the host, potentially revealing information about system activity.
Mitigation: This is mostly metadata leakage, not direct file access.
π Risk #4: Privileged Container Amplification
If you run containers with --privileged or --cap-add=SYS_ADMIN, shared propagation significantly increases the attack surface.
Mitigation: Avoid privileged containers unless absolutely necessary.
Security Context Comparison
| Scenario | Risk Level | Recommendation |
|---|---|---|
| Single-user dev machine, rootless containers only | π’ Low | Shared propagation is generally fine |
| WSL2 on personal Windows machine | π’ Low | Shared propagation is acceptable |
| Multi-user server, rootless containers | π‘ Medium | Evaluate based on trust model |
| Any system with privileged containers | π΄ High | Keep private, or carefully audit |
| Production servers | π΄ High | Use orchestration (K8s) with proper isolation |
Key Security Principle
Mount propagation is not a primary security boundary
User Namespaces
Rootless containers map UID 0 to your user (UID 1000)
Container thinks it's root, but it's actually you
Capability Restrictions
Limited capabilities prevent dangerous operations
No CAP_SYS_ADMIN by default in rootless
SELinux/AppArmor
Mandatory access control policies
File system and process confinement
Seccomp Filters
System call filtering
Blocks dangerous syscalls
Important: Shared propagation slightly weakens isolation but doesn't break these fundamental protections. Your security comes from multiple layers working together.
What Actually Requires CAP_SYS_ADMIN?
Understanding what a container can and can't do helps assess the real risk:
What You CANNOT Do
NO CAP_SYS_ADMIN
Mount Arbitrary Filesystems
Cannot mount host devices directly
mount /dev/sda1 /mnt
Fails: Operation not permitted
Bind-Mount Host Paths
Cannot mount unshared host directories
mount --bind /etc/shadow /tmp/shadow
Fails: Permission denied
Modify System Files
Cannot edit critical system files
echo "hack" > /etc/passwd
Fails: Permission denied
Access Host Network Interfaces
Cannot configure host networking
ip addr add 192.168.1.100/24 eth0
Fails: Operation not permitted
What You CAN Do
ROOTLESS SAFE
Create Overlay/Tmpfs
Mount within container namespace only
mount -t tmpfs tmpfs /tmp/test
Works (but isolated)
Use FUSE Filesystems
User-space filesystems work fine
fuse-overlayfs /merged
Works (user-space)
Manage Container Files
Full control over container filesystem
mkdir /app/data
echo "data" > /app/data/file.txt
Works perfectly
Run Applications
Execute programs as mapped user
npm start
python app.py
java -jar app.jar
Works normally
The Reality Check
Rootless containers are surprisingly capable for development work while maintaining strong security boundaries. The limitations are specifically designed to prevent host system compromise, not to hinder legitimate container usage.
Bottom line: You can do 95% of what you need without CAP_SYS_ADMIN, and the remaining 5% usually involves system-level operations you shouldn't be doing in containers anyway.
6. Practical Fixes π§
Option 1: Temporary Fix (Until Reboot)
# Make root filesystem shared (temporary)
sudo mount --make-rshared /
# Verify the change
findmnt -o TARGET,PROPAGATION /
# Should now show: / shared
# Test with Podman
podman ps -a # Warning should be gone
Note: This fix is lost when you restart WSL2 or reboot your system. You'll need to run it again.
Option 2: Persistent Fix for WSL2
Create a startup script that runs automatically when WSL2 starts:
# Create a startup script
sudo tee /usr/local/bin/fix-mount-propagation.sh > /dev/null <<'EOF'
#!/bin/bash
mount --make-rshared /
EOF
# Make it executable
sudo chmod +x /usr/local/bin/fix-mount-propagation.sh
# Add to /etc/wsl.conf to run on startup
sudo tee -a /etc/wsl.conf > /dev/null <<'EOF'
[boot]
command = /usr/local/bin/fix-mount-propagation.sh
EOF
# Restart WSL2 from PowerShell/CMD:
# wsl --shutdown
# wsl
Option 3: Just Ignore It (When Appropriate)
Safe to Ignore
LOW MAINTENANCE
You can safely ignore the warning if these conditions apply:
No bind mounts
Not using
Not using
-v or --mount flags
Simple mounts only
No nested mount points in your bind mounts
No nested mount points in your bind mounts
Everything visible
No missing files or directories in containers
No missing files or directories in containers
Basic services only
Not running systemd or complex services
Not running systemd or complex services
Pro Tip: Test your specific use case before applying the fix. Run your containers and check if everything works. If it does, the warning is just noise for your workflow.
Option 4: Alternative Container Strategies
Use Volumes
RECOMMENDED
Instead of bind mounts, use Docker/Podman volumes for better isolation
Create volume:
podman volume create mydata
Use volume:
podman run -v mydata:/data myapp
Managed by container runtime, no mount propagation issues
Copy Files
SIMPLE
Build files directly into container images during build
Dockerfile:
FROM node:18
WORKDIR /app
COPY . .
CMD ["npm", "start"]
Immutable images, no runtime mount dependencies
Linux Filesystem
WSL2 OPTIMAL
Keep projects in native Linux filesystem instead of Windows drives
Good:
/home/user/projects/myapp
Avoid:
/mnt/c/Users/user/projects/myapp
Better performance, no Windows mount complexity
Container-Native
PROFESSIONAL
Build self-contained images with everything included
Multi-stage build:
FROM node:18 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build
FROM node:18-alpine
COPY --from=builder /app/dist /app
CMD ["node", "dist/server.js"]
Production-ready, minimal runtime dependencies
Verification Steps
# After applying fix, verify:
# 1. Check propagation
findmnt -o TARGET,PROPAGATION /
# 2. Test with Podman
podman run --rm -v /tmp:/test alpine ls /test
# 3. Check for warning
podman ps -a 2>&1 | grep "not a shared mount"
# (Should return nothing if fixed)
7. When Should You Actually Care? π€
The Decision Tree
Experiencing Problems?
β NO
Containers run successfully
All files visible in bind mounts
No mysterious errors
IGNORE THE WARNING
It's just informational noise
It's just informational noise
β
YES
Directories appear empty
Nested mounts missing
Systemd services fail
APPLY THE FIX
This is likely the cause
This is likely the cause
Use Case Analysis
Safe to Ignore
LOW RISK
Perfect scenarios where the warning is just background noise
Simple web apps
Build environments
Testing containers
Learning Docker
No complex mounts
Go ahead and ignore - you're not affected!
Should Fix
MODERATE RISK
Scenarios where mount issues will cause real problems
Complex directory structures
Systemd in containers
Docker-in-Docker
Kubernetes-in-Docker
FUSE filesystems
Apply the fix to avoid headaches!
The "It Depends" Factors
| Factor | Ignore Warning | Fix It |
|---|---|---|
| Bind Mount Usage | None or simple files only | Complex directory trees with nested mounts |
| Container Complexity | Single-process containers | Multi-service, systemd, or orchestration |
| Development Stage | Learning, experimenting | Production-like testing, CI/CD |
| Time Investment | Want to keep things simple | Need everything to work perfectly |
| WSL2 Restart Frequency | Restart often (temporary fix annoying) | Long-running sessions (fix once, forget) |
Real-World Scenarios
Web Developer
IGNORE
βοΈ Node.js
π³ Docker
π Source Code
Running React app with hot reload
docker run -v ./src:/app/src node-app
Simple bind mount - just source code files, no nested mounts or complex filesystem operations
DevOps Engineer
FIX IT
βΈοΈ Kubernetes
π kind
π K8s-in-Docker
Testing Kubernetes manifests locally
kind create cluster --config kind.yaml
Complex nesting - kind creates nested mount points that require proper propagation
Data Scientist
FIX + MOVE
π Jupyter
πΎ Large Datasets
πͺ Windows Mount
Analyzing data from Windows drive
docker run -v /mnt/c/Data:/data jupyter
WSL2 complexity - Windows mounts + large files = performance issues + mount problems
Move data to
/home/user/data for better performanceCasual User
DEFINITELY IGNORE
π Docker Hub
π¦ Pre-built
π― Simple Usage
Running ready-made containers
docker run postgres redis nginx
No bind mounts - just using pre-built images, no custom filesystem needs
Conclusion π
Mount Propagation
Controls how mount events flow between namespaces - it's about visibility, not permissions
Host
βοΈ
Container
Rootless Security
User namespaces + mount namespaces = limited mount capabilities for safety
Root (UID 0)
β¬οΈ
Your User (UID 1000)
The Warning
Informational, not critical - potential bind mount issues, not immediate danger
π’ Low Risk
WSL2 Architecture
VM architecture means more warnings - virtualized Linux affects mount behavior
Windows
Hyper-V
WSL2 VM
Practical Impact
Modest security implications for typical dev - most workflows unaffected
The Fix
Simple solution but may not be necessary - test before applying
1. Test
2. Evaluate
3. Fix if needed
The Bottom Line
Like many warnings in the Linux world, "/" is not a shared mount is informational rather than critical. It's telling you about a potential edge case that might affect you if you use certain advanced container features.
For most developers running simple containers in WSL2, this warning is harmless background noise. But if you're doing complex mount operations or hitting mysterious issues, now you know exactly what's happening and how to fix it.