The Minor alarm /var partition usage is high on a Juniper EX usually has one of four causes: a leftover install image, old packages kept after an upgrade, runaway logs, or core dumps. A typical r/Juniper post describes it well. One member of a five-unit EX3400 Virtual Chassis raises the alarm, but show system storage does not even list a /var partition. This guide shows where the space actually went and how to free it without breaking the switch.
It was written against Junos OS 23.4 on EX2300, EX3400 and EX4300. It has not been tested on every platform, so check each command on your own release before you rely on it. The newer FreeBSD-based EX2300 and EX3400 images lay out storage differently from EX4300 and older EX platforms, and we flag the differences below.
What the /var Partition Usage Is High Alarm Actually Means
chassisd watches the filesystem that holds /var. It raises a Minor alarm when usage crosses an internal threshold. The alarm is a warning, not an outage. Left alone, though, a full /var can stop logging, block commits, and make upgrades fail with errors such as "not enough space to unpack". The Juniper KB on this alarm also warns that a switch that is out of space may stop accepting logins.
user@ex> show chassis alarms
1 alarms currently active
Alarm time Class Description
2026-09-20 03:12:44 UTC Minor Host 0 /var partition usage is highThat output is a sample. The confusing part on EX2300 and EX3400 is that /var is not a separate partition there. It lives inside the /dev/gpt/junos filesystem mounted at /.mount. So when show system storage shows /.mount at 74 percent, that is your /var figure. On EX4300 and older platforms, you will usually see a separate line mounted on /var.
Why is this alarm so common on small EX switches? Total flash on EX2300 and EX3400 is small. The Juniper KB on storage during EX2300 and EX3400 upgrades explains how the disk is split between partitions. A modern install package is a large share of that space. Junos also keeps the previous package set so you can roll back. Rollback safety and free space pull against each other, and on a small switch you cannot fully have both. That is the design trade-off behind nearly every thread on this alarm.
Step-by-Step Diagnosis: Checks in Order
Work from the cheapest, safest command to the most invasive. Most cases are solved by step 4.
- Find which member raised the alarm with
show chassis alarms. On a VC, it is often one member only. - Run
show system storageon that member to get the real usage figure. - Run
request system storage cleanup dry-runto see what Junos considers safe to remove. - List
/var/tmpand/var/logfrom the CLI and look for large files. - Check for core dumps with
show system core-dumps. - Only then open the shell and measure directories with
du.
user@ex> show chassis alarms
user@ex> request session member 1
user@ex> show system storage
user@ex> request system storage cleanup dry-run
user@ex> file list /var/tmp detail
user@ex> file list /var/log detail
user@ex> show system core-dumpsIf the CLI views do not explain the usage, measure it from the shell. These commands only read and delete nothing:
user@ex> start shell
% cd /var
% du -cks * | sort -rn | head -15
% exitRoot Causes Ranked by Frequency
This ranking is based on forum threads and our experience. Your mix may differ, but check in this order.
1. Install images left in /var/tmp
This is the most common cause. Someone copied a package to upgrade and never deleted it. Or a copy failed halfway and left a partial file behind. The file copy process can also stage a file before moving it, which is why a copy can fail even when /var/tmp looks big enough. Delete old packages from the CLI after you confirm the running version with show version.
2. Old package sets and snapshots after an upgrade
On EX2300 and EX3400, a jump across major trains, for example 18.x to 20.x or later, can leave the old package set under /packages/db. Snapshots can also hold another full image. The Juniper /var partition usage KB documents snapshot deletion for these platforms. It also notes that those commands do not apply to EX4200 or EX4300. Keep one known-good recovery path before you delete, such as a USB image or out-of-band access.
3. Logs and traceoptions that grow without limit
Old traceoptions are a frequent cause. Someone enabled tracing with a large file size during an incident and never removed it. Big packet captures in a home directory are another. DHCP relay logs also appear in real du output shared on r/Juniper. Delete the files, then remove the traceoptions, or cap them with size and files.
4. Core dumps in /var/crash or /var/tmp
A crashing daemon leaves core files, and those can be large. show system core-dumps lists them. Do not just delete them and move on. A core file means something crashed, so copy it off the switch for JTAC before you remove it.
5. The wtmp login record never archived
Juniper has a KB on /var filling because the wtmp login-record file was not rotated. This is less common, but it happens on switches with heavy automated logins. request system storage cleanup rotates logs, so it usually recovers the space.
6. It comes back the next day
If cleanup clears the alarm and it returns within a day, something is writing steadily. A 2025 forum thread on an EX2300 running 23.4R1-S2 found most of the usage in /var/rundb, in files such as render.db and schema.db. Those are internal database files for the management daemon. Do not delete them on a guess. In our experience, recurring growth like this needs a reboot to recover space, an upgrade to a JTAC-recommended release, or a JTAC case.
The Fix: Free Space Safely
Start with the supported cleanup. It rotates logs and removes files Junos knows are safe to remove. Always look at the dry-run list first.
user@ex> request system storage cleanup dry-run
user@ex> request system storage cleanup
user@ex> file delete /var/tmp/junos-arm-32-OLD-RELEASE.tgz
user@ex> show system storageThe file name above is a placeholder. Use the real name from file list /var/tmp detail. On EX2300 and EX3400 in a VC, clean the snapshot and old package space per the KB above:
user@ex> request system snapshot delete * all-members
user@ex> request system snapshot delete previous all-membersThen stop logs and tracing from refilling the disk. These changes do not touch forwarding, but commit them with commit confirmed 5 anyway if the switch is remote:
set system syslog archive size 1m files 5
set system syslog file messages any notice
set system syslog file messages archive size 1m files 5
delete protocols dot1x traceoptions
commit confirmed 5The delete ... traceoptions line is an example. Search your own config with show configuration | display set | match traceoptions and remove what is no longer needed.
What not to delete
The Juniper KB says it plainly. Unless JTAC tells you to, do not delete files outside /var/home from a root shell. The root shell lets you remove system files, and a wrong rm can leave the switch unable to boot. Some community posts delete old package directories under /packages/db by hand. That can work, but only when you are certain the directory does not belong to the running release. Prefer the supported snapshot and cleanup commands.
Quick Reference: Symptom, Cause, Fix
| What you see | Likely cause | Fix |
|---|---|---|
| Large .tgz files in /var/tmp | Leftover install image | file delete after confirming the running version |
| Usage jumped after an 18.x to 20.x+ upgrade | Old package set or snapshot kept | Snapshot delete commands on EX2300/EX3400, or JTAC |
| Large files in /var/log | Traceoptions or syslog without limits | Remove traceoptions, set archive size and files |
| Files listed in show system core-dumps | Crashing daemon | Copy off for JTAC, then delete |
| Alarm on one VC member only | That member has local files | request session member N, then clean up there |
| Alarm returns within a day | Steady writes, often rundb growth | Reboot in a window, upgrade, or open a case |
Verification: What Healthy Output Looks Like
user@ex> show system storage
fpc1:
--------------------------------------------------------------------------
Filesystem Size Used Avail Capacity Mounted on
/dev/gpt/junos 1.3G 560M 696M 45% /.mount
tmpfs 707M 12K 707M 0% /.mount/tmp
tmpfs 324M 464K 323M 0% /.mount/mfs
user@ex> show chassis alarms
No alarms currently activeThese numbers are samples. Healthy means capacity has dropped well below where the alarm fired. The alarm does not always clear the moment space is freed. The Juniper KB reports it clearing by itself after about 20 minutes. If capacity is low and the alarm stays for an hour or more, check whether the alarm is coming from a different VC member.
Related Guides
If DHCP relay logs are growing on a busy access switch, first fix the relay with troubleshooting Junos DHCP relay drop counters. If you enabled flow tracing on an SRX, clean it up the way the SRX security flow traceoptions guide describes. CLI and file-management basics are in the Junos basics section, and more symptom guides are in the troubleshooting hub. The full command options are in the Juniper request system storage cleanup reference. The VC symptom in the opening paragraph comes from this r/Juniper thread.
Frequently Asked Questions
var partition usage is high, but show system storage does not show /var?
On EX2300 and EX3400, /var sits inside /dev/gpt/junos, which is mounted at /.mount. Read that line as your /var usage. Run the command on the member that raised the alarm, using request session member N.
EX storage full, and cleanup command does not help?
Cleanup only removes files Junos considers safe, such as rotated logs. It does not remove install images left in odd places or old package sets. Check file list /var/tmp detail and use the snapshot delete commands on EX2300 and EX3400.
High storage usage on /var reoccuring regularly?
Something is writing steadily. Check for active traceoptions with show configuration | display set | match traceoptions, and measure /var with du to find the growing directory. If the growth is in /var/rundb, do not delete files there. Reboot in a window, upgrade, or open a JTAC case.
Space issues on EX2300 during upgrade?
Free space before you copy the image. Run request system storage cleanup, delete old snapshots, and remove old packages from /var/tmp. Community posts also describe a workaround of staging the image in /var/tmp or /mfs. Check the Juniper EX2300 and EX3400 storage KB for the current recommendation.
Remote EX file copy no space on device?
A copy can need more room than the file size suggests, because the file is staged before it reaches its destination. Clean up first, then retry the copy to /var/tmp. Confirm free space with show system storage before you retry.
Scripting request system storage cleanup: how do I pass yes?
Use request system storage cleanup no-confirm. The option was added in Junos OS 17.3R1. Run the dry-run version in the script first and log what it will remove.
Juniper, Junos, MX, SRX, EX and QFX are trademarks of Juniper Networks, Inc., now part of HPE. juniperclient.com is independent and unaffiliated.
Discussion (0)