Icewhale-files-backup: Docker overlay2 path length errors and unnecessary file copying when backing up to Synology NAS via SMB

Insight & Feedback
1

Environment

  • ZimaOS v1.6.1

  • ZimaBoard with RAID mounted at /media/ZIMASSD

  • Docker data-root on /media/ZIMASSD/docker

  • Backup destination: Synology DS1513+ via SMB mount at /media/192.168.0.22/Zima backup

  • Backup task covers the full ZIMASSD volume

Problem Description

The backup service completes (status: complete) but generates hundreds of errors during each run. Three distinct issues:

Issue 1: Docker overlay2 path length failures

The backup attempts to copy Docker’s internal overlay2 filesystem layers to the Synology via SMB. These paths are extremely deep and hit SMB path length limitations, resulting in repeated “not a directory” errors:

error  File error  {"task_id": "2789690475", "error_type": "unknown", 
"file_path": "/docker/overlay2/cbdf1d01.../merged/run/s6/db/servicedirs/s6rc-fdholder/data/rules/uid/self/env/S6_FDHOLDER_GETDUMP", 
"error_message": "create parent directory failed: mkdir /media/192.168.0.22/Zima backup/ZIMASSD/docker/overlay2/cbdf1d01.../merged/run/s6/db/servicedirs/s6rc-fdholder/data/rules/uid/self: not a directory"}

These overlay2 layers are ephemeral container filesystem layers that Docker rebuilds when pulling images. They are not user data and should not be part of a backup. Backing them up is both unnecessary and unreliable due to path length constraints on SMB destinations.

Suggestion: Either automatically exclude /docker/overlay2 from backup tasks, or allow users to configure exclusion patterns per backup task. The important Docker data (volumes, bind mounts) lives elsewhere and would still be covered.

Issue 2: Repeated “failed to get device model” timeouts

The backup service repeatedly tries to contact the Synology NAS on port 9527, which is a ZimaOS-specific API port. Since the destination is a Synology (not a ZimaOS device), this always times out:

error  failed to get device model  {"error": "failed to get device model: 
Get \"http://192.168.0.22:9527/\": dial tcp 192.168.0.22:9527: i/o timeout"}

This happens many times per backup run, adding unnecessary network traffic and log noise.

Suggestion: After the first failed attempt to detect a ZimaOS device, cache the result and stop retrying for that storage destination during the current backup run. Or only attempt device detection once per task, not on every poll.

Issue 3: Unix socket copy failures

The backup attempts to copy Unix socket files (e.g. Poste.io’s rspamd.sock) which cannot be transferred over SMB:

error  File error  {"task_id": "2920841825", "error_type": "unknown", 
"file_path": "/AppData/postemail/data/var/rspamd/rspamd.sock", 
"error_message": "copy special file with cp failed: exit status 1"}

Suggestion: Skip socket files (type s) and other special files (pipes, device nodes) during backup. They are runtime artifacts and cannot be meaningfully restored.

Summary

None of these errors prevent the backup from completing, but they generate excessive log noise (hundreds of entries per run), consume 4.7GB of memory during the process, and make it difficult to identify real problems. The backup service would benefit from:

  1. An exclusion mechanism for paths like /docker/overlay2

  2. Smarter device detection that doesn’t retry indefinitely on non-ZimaOS targets

  3. Automatic skipping of special files (sockets, pipes, device nodes)

Happy to provide full logs or additional details if helpful. Overall the backup feature is very useful — these are refinements that would make it more robust for users with Docker-heavy setups and non-ZimaOS backup destinations.