Game Server Disk Full: What to Check Before Deleting World Data
Published and official references checked 2026-09-07 · SameOS operator
If players can join but saves fail or progress disappears after restart, inspect storage. Deleting the largest folder in a hurry can confuse an old backup with the live world. Identify the exhausted filesystem, reduce new writes and distinguish recoverable disposable data from saves you must keep.
1. Stop repeating restarts after save errors
No space left on device, Disk quota exceeded, Read-only file system and Permission denied indicate different problems. Preserve the exact error and path rather than treating every failed write as a permissions issue. A running process does not prove successful saves.
Announce maintenance and reduce new joins, backup jobs and updates. Attempt the game-supported save and graceful stop, checking completion. Saving cannot be guaranteed when no space remains. Repeated forced stops and restarts make the last good state harder to identify.
2. Inspect the filesystem that actually holds the save
Replace /srv/minecraft/data with the real save path, and check the backup path separately. The root disk can have room while the save disk is full. df -i checks inode usage separately from data blocks.
Huge numbers of small files can exhaust inodes with bytes still available. Full block storage with spare inodes suggests large archives or logs. Quotas and read-only transitions need separate investigation; usage percentages alone do not explain them.
df -hT /srv/minecraft/data
df -i /srv/minecraft/data
df -hT /srv/game-backups3. Check Docker mounts and missing disks
Container paths can map to different host storage. Inspect whether game data uses a bind mount or a named volume. An unfamiliar volume name does not mean temporary data: it may hold the world that must survive container recreation.
If an external disk fails to mount after reboot, a game may create a new world at the same path on the root filesystem. Check the device reported by findmnt. An apparently empty directory can mean a missing mount, not a deleted world.
docker inspect --format '{{json .Mounts}}' mc-server
findmnt -T /srv/minecraft/data
docker system df4. List large consumers and identify their role
Use du to narrow directory usage. -x stays on one filesystem and -d 1 summarizes one level. Restrict the path because traversal itself adds disk I/O.
Review obsolete release archives, failed downloads, duplicate backups and excess logs first. Do not automatically classify current saves, mod databases, player files or the last recoverable backup as disposable.
Large df/du differences can involve deleted files still held open, snapshots or inaccessible directories. If installed, lsof can identify deleted open files. Identify the owner and plan a graceful restart rather than killing a game because a filename looks large.
sudo du -xhd 1 /srv
sudo du -xhd 1 /var/log
sudo lsof +L15. Bound future log growth
Docker json-file logs can grow without rotation. Merge the logging fragment below into your existing Compose service; it is not a complete game deployment. The 10m/3 values are an example, to be adjusted for log volume and required history.
New logging options do not automatically update existing containers. Confirm persistent mounts and backups, then schedule graceful recreation. Avoid directly truncating Docker-managed logs. Adding this configuration alone does not immediately free a full disk.
services:
minecraft:
logging:
driver: json-file
options:
max-size: "10m"
max-file: "3"6. After reclaiming space, verify a save and reload
Before moving files away, verify the destination is actually another filesystem and the copy is readable. Renaming directories on the same filesystem frees no space. Check backup integrity as well as dates so an incomplete archive is not mistaken for the last good one.
Recheck permissions, mounts and read-only state before starting the game. Confirm the intended world and players, save a small change and verify it survives a graceful restart. If a save is damaged, validate a restore separately instead of repeatedly overwriting production.
Monitor remaining bytes, inodes and growth as well as percent used. Allow room for update downloads, temporary backup files and saves that overlap. Define backup retention and log rotation before the next incident.
Verification scope and official references
This Linux operations guide was checked against the linked documentation and command options. Paths, service names, addresses and diagnostic scenarios are illustrative, not incident reports or performance measurements from SameOS game servers. We did not induce production failures or modify production saves. Confirm paths and behavior for your game build and deployment before applying changes.