Storj Filewalker Fix: Stop Your Server Fan Running at Max 24/7

One morning I noticed my Mac Mini’s fan was running at maximum, 24/7. It had been for days.

My first thought: Is my passive income server dying?

It wasn’t. The culprit was Storj’s filewalker — and the fix took five minutes. Here’s the full diagnosis and solution.

The Symptom

• Server fan running at max constantly
• High CPU usage that never settles
• Often starts right after the node restarts (e.g. after an update)

If your Storj node is large or near-full, this is extremely common.

Step 1: Confirm It’s Storj

SSH into your server and check what’s eating the CPU:

1

docker stats --no-stream

If you see storagenode at 100%+ CPU like this, you’ve found it:

The huge block I/O number is the giveaway — the node is reading enormous amounts of data from disk. That’s the filewalker scanning your stored pieces.

You can confirm with the logs:

1

docker logs --since 2h storagenode 2>&1 | grep -i "filewalker\|used-space\|gc\|trash"

If you see used-space-filewalker or gc-filewalker entries, that’s your answer.

Step 2: Understand What’s Happening

The filewalker isn’t a bug — it’s necessary maintenance. Storj runs it to:

• Calculate disk usage (used-space filewalker)
• Find and delete unneeded pieces (garbage collection)
• Empty the trash (trash cleanup)

The problem is the default behavior: it runs a full scan on every startup, at normal priority. On a near-full multi-TB node sitting on a single HDD, that scan can take hours and saturate your CPU and disk the entire time.

Important: Your hardware is almost certainly fine. When this happened to me, my CPU temp was a cool 42°C — nowhere near dangerous. The fan was just reacting to sustained load, not heat.

Step 3: The Fix

The solution is two flags:

You add these by recreating the container. Your data and identity are safe — they live on disk, not in the container.

Stop and remove the old container

1

docker stop storagenode && docker rm storagenode

(Don’t panic — this does NOT delete your data or identity.)

Recreate with the fix

Use your existing run command and append the two flags at the end. A typical command looks like:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

docker run -d --restart unless-stopped --stop-timeout 300 \
  --name storagenode \
  -p 28967:28967/tcp \
  -p 28967:28967/udp \
  -p 14002:14002 \
  -e WALLET="YOUR_WALLET" \
  -e EMAIL="YOUR_EMAIL" \
  -e ADDRESS="YOUR_ADDRESS:28967" \
  -e STORAGE="3.3TB" \
  --mount type=bind,source="/path/to/identity",destination=/app/identity \
  --mount type=bind,source="/path/to/config",destination=/app/config \
  storjlabs/storagenode:latest \
  --storage2.piece-scan-on-startup=false \
  --pieces.enable-lazy-filewalker=true

Tip: Before removing the old container, save your current run command. You can recover the exact paths with:

1	docker inspect storagenode --format '{{range .Mounts}}{{.Source}} -> {{.Destination}}{{println}}{{end}}'

The --stop-timeout 300 is a bonus — it gives Storj 5 minutes to shut down cleanly on restart, which protects your reputation.

Step 4: Verify

After recreating, confirm the node is healthy:

1
2

docker ps | grep storagenode
docker logs --tail 20 storagenode 2>&1 | grep -iE "started|error|fatal"

You want to see it running with no FATAL errors. Then confirm it’s earning:

1

docker logs --tail 10 storagenode 2>&1 | grep -iE "downloaded|uploaded"

downloaded lines mean satellites are pulling data from your node — you’re earning egress again.

The Result

After applying the fix:

• CPU usage dropped from 124% to normal levels
• The fan calmed down within a few hours
• The lazy filewalker now runs maintenance quietly in the background
• Zero impact on earnings — the node passed audits within minutes of restarting

When the Filewalker Still Runs

Even with these flags, the lazy filewalker will still run periodically — that’s intentional and good. The difference is it runs at low priority, so it doesn’t max out your CPU or fan. You might hear the fan ramp up briefly during cleanup, but not the constant 24/7 roar.

Key Takeaways

1. Maxed fan + high Storj CPU = the filewalker. It’s maintenance, not malfunction.
2. Check the temperature before worrying — high load doesn’t mean overheating.
3. Two flags fix it permanently: disable startup scan, enable lazy filewalker.
4. Your data is safe when recreating the container — it lives on disk.
5. No earnings impact — the node resumes immediately and passes audits.

For more on running a healthy node, see my Storj setup guide and how full your node should be.

Run the Whole Stack

Storj is one of 8 passive income apps I run on a single Mac Mini. See my monthly earnings reports for the real numbers.

Part of my ongoing passive income experiment. Goal: $5,000 by end of 2026.