Every Linux server failure I’ve seen from disk issues starts the same way:
Root slowly fills up.
No alarms. No drama. Just creeping usage.
On this Ubuntu server, / was sitting at a safe percentage — but something wasn’t right. A quick disk usage scan showed the real issue:
/opt 141G
Large directories on root are a warning sign. And on Docker hosts, the usual culprit is container storage.
Rather than wait for the root filesystem to fill and crash services, I made a structural fix:
I moved Docker completely off the root disk.
Here’s how.
Why Moving Docker Matters
By default, Docker stores everything under:
/var/lib/docker
That includes:
- Images
- Containers
- Volumes
- Build cache
- Overlay filesystem layers
On active systems, this can grow into hundreds of gigabytes.
When root fills:
- Docker stops
- systemd fails
- Logs stop writing
- SSH may fail
- The server can become unstable
Best practice: separate OS storage from container storage.
The Proper Fix: Move Docker’s Data Root
Instead of deleting images repeatedly, the right solution is to move Docker’s data directory to a secondary disk.
In this case, the secondary drive was mounted at:
/mnt/1TB
The new Docker path:
/mnt/1TB/docker-data
Step-by-Step: Move Docker to Another Drive (Ubuntu)
Step 1 — Confirm the Secondary Drive Is Mounted
Verify mount:
df -h
Ensure your secondary disk appears mounted at your intended path.
Also confirm UUID-based mount in /etc/fstab:
cat /etc/fstab
This prevents mount issues after reboot.
Step 2 — Stop Docker
sudo systemctl stop docker
sudo systemctl stop docker.socket
Step 3 — Create the New Docker Directory
sudo mkdir -p /mnt/1TB/docker-data
sudo chown root:root /mnt/1TB/docker-data
sudo chmod 711 /mnt/1TB/docker-data
Step 4 — Copy Existing Docker Data
Preserve permissions and metadata:
sudo rsync -aP /var/lib/docker/ /mnt/1TB/docker-data/
Important: the trailing slash matters.
Step 5 — Configure Docker
Edit:
sudo nano /etc/docker/daemon.json
Add:
{
"data-root": "/mnt/1TB/docker-data"
}
If you use GPU runtime, include those runtime settings as needed — but the only required change for relocation is "data-root".
Save the file.
Step 6 — Backup the Old Docker Directory
sudo mv /var/lib/docker /var/lib/docker.bak
This gives you rollback protection.
Step 7 — Start Docker
sudo systemctl start docker
Step 8 — Verify the New Location
docker info | grep "Docker Root Dir"
Expected:
Docker Root Dir: /mnt/1TB/docker-data
Step 9 — Clean Up After Verification
Once confirmed working:
sudo rm -rf /var/lib/docker.bak
Production-Safe Boot Protection
One critical issue many guides miss:
If Docker starts before the secondary drive mounts at boot, it may recreate /mnt/1TB/docker-data on root.
To prevent this, create a systemd override:
sudo mkdir -p /etc/systemd/system/docker.service.d
sudo nano /etc/systemd/system/docker.service.d/override.conf
Add:
[Unit]
RequiresMountsFor=/mnt/1TB
Reload:
sudo systemctl daemon-reload
Now Docker will not start unless the drive is mounted.
Final Result
After this change:
- Root remains stable
- Docker storage is isolated
- Disk growth is predictable
- Server stability improves significantly
This is not a cleanup tactic — it’s structural infrastructure design.
Takeaway
If you run Docker on Ubuntu and care about uptime:
- Do not let
/var/lib/dockerlive on root. - Use a separate mounted volume.
- Enforce mount dependency.
- Protect your OS partition.
Disk space issues don’t explode suddenly.
They accumulate quietly.
Separating Docker storage is one of the simplest and most effective ways to prevent a future outage.
Leave a Reply