NinjaOne Backup — Error 10053 & 10054: Connection Aborted / Reset
Audience: T2 Use when: Backup fails with "Error 10053: Connection aborted by host machine" or "Error 10054: Connection reset by host machine."
These are Windows Sockets (Winsock) error codes surfaced through Lockhart during the cloud upload phase.
10053 vs. 10054 — The Difference
| Code | Winsock Name | What Happened |
|---|---|---|
| 10053 | WSAECONNABORTED | The local machine (the device running Lockhart) terminated the TCP connection — something on the device's side cut it off |
| 10054 | WSAECONNRESET | The remote host (NinjaOne's AWS endpoint) forcibly closed the connection — the server reset the connection |
In practice at DTC sites, both present similarly and have overlapping causes. Triage both the same way.
Common Causes
| Cause | More Likely For |
|---|---|
| IDS/IPS or deep packet inspection on the UDM terminating long-lived upload sessions | 10053 |
| Firewall session timeout dropping established connections | 10053 |
| NinjaOne/AWS endpoint closing a stale or timed-out session | 10054 |
| ISP-level traffic shaping interrupting large upload streams | Either |
| MTU mismatch causing TCP session failure under load | Either |
| VPN or tunnel interference | Either |
Step 1 — Check If This Is Recurring or Isolated
Review the NinjaOne activity log for this device. If it's happened once or twice during a long initial backup: this is likely transient. NinjaOne resumes from the last block checkpoint — let it run and monitor.
If it's occurring nightly and the backup never completes: investigate.
Step 2 — Check UDM IPS/IDS Settings
UniFi's Intrusion Prevention System (IPS) can flag or terminate long-lived upload sessions that look anomalous:
- UniFi → Settings → Security → IPS
- Check if IPS is in blocking mode (Prevent) vs. detection-only (Detect)
- If in Prevent mode: review threat categories — some aggressive rulesets block large sustained uploads to cloud endpoints
- Consider adding NinjaOne/AWS endpoints to an IPS allowlist or whitelist
Step 3 — Check for Firewall Session Timeouts
Stateful firewalls track TCP sessions. If a session is quiet for longer than the timeout period (even if data is still flowing slowly), the firewall kills it:
# Check TCP keepalive settings on the device
netsh int tcp show global
# Set keepalive to reduce session idle time
netsh int tcp set global keepalivetime=60000
netsh int tcp set global keepaliveinterval=1000
On the UDM: Settings → Firewall → check if any WAN out rules have aggressive session timeouts.
Step 4 — MTU Check
A mismatch between the device's MTU and the path MTU can cause large TCP segments to fail silently, leading to connection aborts:
# Test large packet delivery to NinjaOne cloud
ping backup.ninjarmm.com -f -l 1472 # Standard Ethernet MTU minus headers
ping backup.ninjarmm.com -f -l 1400 # Reduced test
ping backup.ninjarmm.com -f -l 1300 # Further reduced
# If 1472 fails but 1300 works: MTU is the issue
Fix: set WAN MTU to 1400 on the UDM (Settings → Internet → Advanced), or enable MSS clamping.
Step 5 — Restart Lockhart and Retry
After addressing any of the above:
Get-Service | Where-Object {$_.DisplayName -like "*Lockhart*"} | Restart-Service -PassThru
Trigger a manual backup run. Monitor the upload leg to completion.
Escalate to T2 If:
- IPS changes and MTU adjustments don't resolve recurring failures
- Multiple sites experiencing these errors simultaneously (NinjaOne platform issue)
- 10054 persists after all local changes — may be a NinjaOne-side session issue