You have space, but the system says no
You run sudo dnf install firefox and the transaction aborts with Error: No space left on device. You panic and run df -h. The output shows 40% usage on /. You stare at the terminal. The disk is half empty, but the system refuses to write a single byte.
This happens. The error message is literal, but "space" means different things to different parts of the kernel. You need to check what the filesystem is actually tracking, not just the block count. Fedora uses multiple storage mechanisms, and any one of them can hit a hard limit while the main disk looks healthy.
What the kernel is actually tracking
A filesystem tracks two independent resources: blocks and inodes. Blocks store the actual data bytes. Inodes store the metadata: permissions, ownership, timestamps, and pointers to the blocks.
Think of a library. Blocks are the pages inside the books. Inodes are the index cards in the catalog drawer. You can have a library full of empty books with plenty of blank pages, but if the catalog drawers are jammed with index cards, the librarian cannot check out a new book. The system reports "no space" because it cannot create the metadata entry required to record the new file, even if the physical storage is available.
Fedora also mounts /tmp as a RAM-backed filesystem and reserves a percentage of blocks for root access on ext4 partitions. Any of these limits can trigger the exact same error string. The fix depends on which resource is exhausted.
Diagnose inode exhaustion
Inodes are fixed at format time. An ext4 filesystem on a 4TB drive has the same inode count as one on a 500GB drive if formatted with default settings. This means large drives are actually more susceptible to inode exhaustion per gigabyte of storage. If you store email in Maildir format, use a container runtime that creates thousands of layers, or have a build cache with millions of small files, you burn inodes fast.
Run this command to check inode usage:
df -i
# WHY: Displays inode usage percentages for all mounted filesystems.
# Look for IUse% near 100. Blocks can be free while inodes are exhausted.
If a filesystem shows 100% inode usage, you need to find the directory hoarding the files. This command counts files per top-level directory to locate the culprit:
sudo find / -xdev -type f | cut -d/ -f2 | sort | uniq -c | sort -rn | head -10
# WHY: Counts files per top-level directory to locate inode hogs.
# -xdev prevents crossing mount points like /home or /boot.
# The output lists directories with the highest file counts first.
Drill down into the offending directory with find until you isolate the cache or log folder. Delete the unnecessary files. Inodes do not regenerate until the filesystem is reformatted.
Delete the millions of tiny files. Inodes do not regenerate until the filesystem is reformatted.
Clear the temporary filesystem
Fedora mounts /tmp as tmpfs in RAM. This ensures temporary files do not persist across reboots and speeds up access. The size limit is dynamic. systemd sets the limit to half of physical RAM by default. If you have 16GB of RAM, /tmp can grow to 8GB. A runaway process writing to /tmp can consume that 8GB and trigger the error, even if your disk has terabytes free.
Check the temporary filesystem status:
df -h /tmp
# WHY: Checks the RAM-backed filesystem size and usage.
# tmpfs grows dynamically up to the configured limit, usually half of RAM.
Clear the contents if usage is high:
sudo rm -rf /tmp/* /tmp/.[!.]*
# WHY: Removes visible and hidden files in /tmp.
# The glob /tmp/.[!.]* catches hidden files that the first glob misses.
# Active processes may fail if they rely on files currently in /tmp.
Clear /tmp before the next reboot. The filesystem lives in RAM and vanishes on power loss anyway.
Adjust reserved block space
Ext4 reserves 5% of blocks for root by default. This reservation exists so that root can still write logs and fix the system when the disk is full. On a desktop system with a 2TB drive, 5% is 100GB. That is 100GB of space that dnf cannot use for packages. If your free space drops below the reservation threshold, user processes fail even though root could theoretically write.
Find the device backing the root filesystem and check the reservation:
sudo tune2fs -l /dev/nvme0n1p2 | grep 'Reserved block count'
# WHY: Shows the current reservation percentage for the partition.
# Replace /dev/nvme0n1p2 with your actual root partition device.
# The output displays the count and percentage of reserved blocks.
Reduce the reservation to 1% on large data drives:
sudo tune2fs -m 1 /dev/nvme0n1p2
# WHY: Reduces reserved blocks to 1%.
# This frees space for user processes but reduces root safety margin.
# This command only works on ext2/ext3/ext4 filesystems.
Lower the reservation on large data drives. Keep the default on small boot partitions where root access matters.
Manage journal logs
Fedora uses systemd-journald for logging. The journal rotates automatically, but a burst of errors can cause logs to grow rapidly. Fedora caps the journal at 10% of the filesystem by default, but this cap applies to the partition, not the total disk. If /var is on a small partition, the journal can fill it quickly.
Check the journal disk usage:
sudo journalctl --disk-usage
# WHY: Reports total size of persistent journal logs.
# Fedora caps this at 10% of the filesystem by default.
# The output shows the current byte count of stored logs.
Vacuum the journal to reclaim space:
sudo journalctl --vacuum-size=500M
# WHY: Truncates logs to fit within 500MB total.
# Use --vacuum-time=7d to keep only the last week instead.
# This command removes the oldest entries first.
Check journalctl -xe for the actual error context before vacuuming. The -x flag adds explanatory text and -e jumps to the end. This helps identify which service is spamming the logs so you can fix the root cause.
Vacuum the journal before debugging. Old logs consume space and slow down journalctl queries.
Reclaim package cache
dnf caches downloaded RPM packages and repository metadata in /var/cache/dnf. This cache speeds up repeated installs but can accumulate gigabytes of data over time, especially after major upgrades where old packages remain.
Clean the cache:
sudo dnf clean all
# WHY: Removes cached RPM packages and metadata.
# This reclaims space in /var/cache/dnf immediately.
# Run this after a major upgrade to remove old package files.
Run dnf upgrade --refresh weekly to keep metadata fresh. This prevents dependency resolution errors that can look like space issues when the cache is stale.
Run dnf clean all after a major upgrade. The old packages sit in the cache until you tell them to leave.
Verify the fix
Run both block and inode checks to confirm the error is resolved:
df -h / && df -i /
# WHY: Confirms both block and inode usage are within safe limits.
# Both commands must show free resources for the error to resolve.
# The && operator ensures the second command runs only if the first succeeds.
Test the original command that failed. If dnf or the application still reports no space, the error is elsewhere.
Test the original command. If dnf or the application still fails, the error is elsewhere.
Common pitfalls
You deleted files but df still reports the disk is full. This happens when a process holds an open file descriptor to a deleted file. The space remains occupied until the process closes the descriptor or exits.
Find files that are deleted but still open:
sudo lsof +L1
# WHY: Lists files that have been deleted but are still held open by a process.
# The space remains occupied until the process closes the file descriptor.
# Look for the COMMAND column to identify which service to restart.
Restart the offending service to release the space.
Fedora Workstation uses btrfs by default. btrfs reports space differently than ext4. It allocates space in chunks for data and metadata. df shows the total chunk allocation, not just the used bytes. You can see free space in df but btrfs cannot allocate a new chunk because the free space is fragmented or reserved for metadata.
Check btrfs usage:
sudo btrfs fi usage /
# WHY: Displays btrfs space allocation details including data and metadata chunks.
# Look for 'Device' lines to see total size and 'Used' to see actual consumption.
# btrfs can show free space that is not available for new allocations.
Check open file handles before rebooting. A deleted log file held by a daemon will not release blocks until the service restarts.
Which tool to use
Use df -i when df -h shows free blocks but writes still fail.
Use tune2fs -m 1 when you have a large ext4 partition and user processes are starving for space.
Use journalctl --vacuum-size when the journal has grown beyond the configured cap due to a burst of errors.
Use rm -rf /tmp/* when a build process or application has filled the RAM-backed temporary filesystem.
Use btrfs fi usage when running Fedora Workstation with the default btrfs layout and standard tools show confusing space reports.
Use lsof +L1 when you deleted files but df still reports the disk is full.