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/docker live 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.