This is a follow-up to the OneDrive Proxmox LXC ZFS Mirror setup guide. After running the setup for a few days, you might notice something odd in the Proxmox container summary: regular Disk IO spikes of 8–14 MB/s appearing every five minutes like clockwork — even though the initial sync finished long ago and nothing in OneDrive has changed. This post explains exactly why this happens and how to fix the OneDrive Proxmox LXC disk IO problem in a way that’s safe for both single- and multi-account setups. 🔧
What the Proxmox Graph Is Telling You 📊
Open your Proxmox web UI, navigate to the LXC container summary, and look at the Disk IO panel. You’ll see periodic read spikes (yellow-green) with consistent low-level write activity (blue) between them, repeating on a fixed schedule. This is the most visible symptom of the OneDrive Proxmox LXC disk IO problem — and it shows up on every installation running default settings.
This is not a bug, a runaway process, or a sign that something is broken. It is the OneDrive client doing exactly what it was configured to do — just more aggressively than necessary for a download-only mirror setup. The Proxmox LXC container documentation explains the Disk IO graph in detail if you want to understand what each channel represents.
Root Cause: What Happens Every 300 Seconds 🔍
The abraunegg OneDrive client in --monitor mode runs a periodic cycle controlled by one setting: monitor_interval. The default value is 300 seconds — five minutes. You can find the full list of supported configuration options in the official abraunegg/onedrive configuration documentation.
On every cycle the client does three things:
- Full local filesystem scan — reads the mtime and size of every tracked file to detect local changes
- SHA1 hash comparison — verifies file integrity for changed candidates
- SQLite database write — updates
items.sqlite3with the scan results, regardless of whether anything changed
In the OneDrive Proxmox LXC ZFS Mirror setup, the items.sqlite3 database grows to 100+ MB as it indexes tens of thousands of files. Writing and checkpointing that database every five minutes — forever — is the direct cause of the OneDrive Proxmox LXC disk IO spikes you see on the graph.
The irony is that for a download_only = "true" setup, local change detection is irrelevant. Files are only ever written by the sync client itself, not by users or other processes. There is nothing meaningful to scan for.
Why WebSocket Changes Everything 🌐
Since abraunegg/onedrive v2.4.x, the client supports Microsoft Graph API WebSocket notifications. When this is active, the server pushes a notification the moment a file changes in OneDrive — the client doesn’t need to poll the API on a timer to discover remote changes. This is the key reason why reducing OneDrive Proxmox LXC disk IO is safe: you lose nothing in terms of sync responsiveness.
You can confirm WebSocket is working by checking the service logs:
# Check that WebSocket connected successfully at startup
journalctl -u onedrive-work.service --no-pager | grep -i websocketYou should see:
Attempting to enable WebSocket support to monitor Microsoft Graph API changes in near real-time.
Enabled WebSocket support to monitor Microsoft Graph API changes in near real-time.With WebSocket active, monitor_interval no longer drives remote change detection. Its only remaining job is triggering the local filesystem scan — which, for download_only = "true", doesn’t need to happen every five minutes.
The Fix: Three Config Parameters ⚙️
Edit the config file for each account:
# Open config for the first account
nano /root/.config/onedrive-work/configReplace the contents with:
sync_dir = "/mnt/onedrive/work"
download_only = "true"
log_dir = "/var/log/onedrive/"
skip_file = "~*|.~*|*.tmp"
monitor_interval = "3600"
monitor_fullscan_frequency = "168"
enable_logging = "true"💡 Key config options explained:
download_only = "true"— only pulls from OneDrive, never uploads or deletes from cloud. Remove if you want bidirectional sync.monitor_interval = "3600"— poll interval in seconds (1 hour). WebSocket handles real-time changes between polls.monitor_fullscan_frequency = "168"— full database consistency check every 168 cycles = once per week. Setting this too low (e.g. 24) causes high CPU load every day on large libraries.
⚠️ Avoid cleanup_local_files = "true" unless you’re certain you want it. Combined with download_only, this will delete local files if they disappear from OneDrive — including files you may have deleted accidentally in the cloud.
Repeat for every account:
# If you have additional accounts, edit each config the same way
nano /root/.config/onedrive-personal/config
nano /root/.config/onedrive-work/configApply the Changes 🔄
⚠️ Important: The abraunegg client detects configuration changes that affect sync behaviour and refuses to start until you run
--resync. This is not an error — it’s a safety mechanism to prevent the local database from becoming out of sync with the new settings. You will see this message in the logs if you skip this step:An application configuration change has been detected where a --resync is required
This applies every time you change monitor_interval, monitor_fullscan_frequency, check_nosync, or any other sync-related parameter. Always run --resync after editing the config — before restarting the service.
Step 1 — Stop the service:
# Stop each service before running resync
systemctl stop onedrive-work.service
systemctl stop onedrive-personal.serviceStep 2 — Run resync for each account:
# This rebuilds the local state database from the current OneDrive state
# It does NOT re-download all your files — only checks what needs updating
onedrive --confdir /root/.config/onedrive-work --resync --sync
onedrive --confdir /root/.config/onedrive-personal --resync --syncType Y when prompted. Wait for each one to complete — this may take a few minutes depending on the number of tracked files. 🕐
Step 3 — Start the services:
# Start each service after resync completes
systemctl start onedrive-work.service
systemctl start onedrive-personal.serviceStep 4 — Verify the new interval in logs:
# Confirm the new interval is active
tail -30 /var/log/onedrive/work.log | grep -i "interval\|WebSocket"
tail -30 /var/log/onedrive/personal.log | grep -i "interval\|WebSocket"You should see:
Enabled WebSocket support to monitor Microsoft Graph API changes in near real-time.
OneDrive synchronisation interval (seconds): 3600After the restart, OneDrive Proxmox LXC disk IO activity should drop noticeably within the first 10 minutes as the constant 5-minute cycle disappears. 📉
What Each Parameter Actually Does 🧠
monitor_interval = "3600" — Sets how often the client wakes up to scan local files and check the API. Raising it from 300 to 3600 reduces that cycle from 288 times per day to 24 times per day. Between cycles, WebSocket handles everything from the cloud side.
monitor_fullscan_frequency = "24" — Controls how many monitor_interval cycles pass before the client does a complete rescan of both local files and the remote delta. At 24 × 3600s, this triggers once every 24 hours. It’s a safety net for cases where WebSocket missed a notification.
check_nosync = "true" — Tells the client to rely on file size and modification time when comparing local files, instead of computing and comparing SHA1 hashes. This eliminates the most CPU- and IO-intensive part of each scan cycle.
Before and After 📉
| What changes | Before | After |
|---|---|---|
| Local scan frequency | Every 5 minutes | Every 60 minutes |
| SQLite write cycles per day | 288 | 24 |
| Remote change detection | Polling every 5 min | WebSocket real-time |
| Full rescan | Every 5 min | Once per day |
| Disk IO spikes | Constant | Rare |
The OneDrive Proxmox LXC disk IO spikes don’t disappear entirely — you’ll still see activity once per hour when the scan cycle runs, and whenever a real file arrives via WebSocket. But the constant background noise every five minutes is gone.
A Note on RAM Usage 🐏
The abraunegg client keeps the full file index in memory. If you’re mirroring a large OneDrive account (100K+ files), expect 1–2 GB of RAM usage per instance — this is normal and unrelated to the OneDrive Proxmox LXC disk IO problem. The 3 config changes above do not affect RAM behavior. If RAM is a concern, the only lever is reducing the scope of what gets synced using skip_dir or selective sync configuration — see the abraunegg/onedrive selective sync guide for details.
Related Posts
🔒 Self-Host WireGuard VPN on Proxmox in Minutes
🗄️ OneDrive Proxmox LXC ZFS Mirror: Easy 7-Step Setup Guide — the setup this post builds on