Der neue Monatsrückblick für Mai und Juni 2026 ist online!

[Rico Sander]

Frage an die Linuxspezialisten:
Das tägliche BackUp lief und läuft eigentlich ohne Probleme.
BackItUp mounted einen USB-Stick der an der Synology hängt und liefert dort seine BackUps ab. Mounten funktionierte und funktioniert soweit ohne Probleme.

Seit einiger Zeit jedoch erhalte ich sporadisch diesen Fehler, den ich konkret keinem Update oder anderen Prozessen zeitlich zuordnen kann.
Soweit ich das verstehe, wird das NAS als beschäftigt angesehen. Alternativ wird angenommen, dass das NAS schon gemounted ist.

Error: Command failed: sudo mount -t cifs -o username=xxx,password=****,domain=DISKSTATION,noserverino,rw,forceuid,uid=iobroker,forcegid,gid=iobroker,file_mode=0777,dir_mode=0777 //192.168.178.3/usbshare1/iobroker_backup /opt/iobroker/backupsmount error(16): Device or resource busyRefer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)

Ich hatte die Backup-Zeit schon verschoben, falls da mir unbekannte Prozesse laufen. Half aber auch nicht.
Da ich selbst nix geändert habe, weiß ich jetzt nicht wo ich suchen soll. An der Konfiguration vom BackItUp wurde nix geändert, am NAS auch nicht.

Es gab zwar ein Update des NAS OS, aber das hatte keine unmittelbaren Auswirkungen. Müsste daher als Ursache ausscheiden. Update vom ioB waren auch ohne Auswirkungen, denn auch danach gab es nicht sofort diesen Fehler. Er tritt zudem auch ohne erkennbares System auf.

Any idea?
Danke schon mal und ein angenehmes Wochenende.

[Thomas Braun]

@Rico-Sander

Schau dir an, was da bereits zugreift:

sudo lsof +D /opt/iobroker/backups

Und nimm mal die 'noserverino'-Option raus.

Das ganze kann passieren, wenn die Netzwerkverbindung wackelig ist oder der USB-Stick zu langsam ist (oder ein 'non-linux-filesystem hat). Warum mountest du nicht was direkt aus dem NAS?

[Rico Sander]

@Thomas-Braun sagte:

Zunächst danke für Deine Rückmeldung.

sudo lsof +D /opt/iobroker/backups

lsof ist nicht installiert, muss ich nachholen.

Und nimm mal die 'noserverino'-Option raus.

Ok, mach ich und werde es beobachten.

Das ganze kann passieren, wenn die Netzwerkverbindung wackelig

Ich denke, das kann ich ausschließen, alles über LAN auf kurzem Weg.

oder der USB-Stick zu langsam ist

Möglich, aber eher unwahrscheinlich. Aber ja, den könnte ich nach Tausch als Fehlerquelle ausschließen.

(oder ein 'non-linux-filesystem hat)

Ah, guter Hinweis. Nach dem Wechsel des Sticks wegen Kapazitätsmangel habe ich ihn bei NTFS belassen - also schlicht vergessen zu formatieren.
Muss ich ändern und beobachten

Warum mountest du nicht was direkt aus dem NAS?

Aus historischen Gründen aus der "Vor-ioB-Zeit". Die beiden Festplatten sind "thematisch" gut ausgelastet und ich wollte damals nicht mehr vermischen, als notwendig. So ist ioB wenigstens etwas physisch vom restlichen Datenbestand getrennt. Ok, muss man nicht verstehen ...

Kurz:
Es muss also etwas gegeben haben, was sich geändert hat, denn dieses Problem hatte ich eigentlich davor nie. Deine Hinweise werde ich mal abarbeiten und schauen, ob ich die Ursache finde.

Kann natürlich dauern, da der Effekt nur sporadisch auftritt. Ich würde mich zu gegebener Zeit dann hier nochmal melden.

Danke und schönen Sonn(en)tag.

[Rico Sander]

@Thomas-Braun
"Kurze" Rückmeldung: (tl;dr)

• Die option 'noserverino' war nicht Ursache
• Der Wechsel von NTFS zu ext4 auf dem USB war auch nicht die Ursache, dazu später
• Der Wechsel vom USB-Stick als Sicherungsziel zur Festplatte schien zunächst erfolgreich zu sein
• Dann gab es aber DB-Fehler

backitup.0 error	[iobroker] Error: EIO: i/o error, read
backitup.0	error	[iobroker/historyDB] Error: EIO: i/o error, read

• erste Vermutung: Der Stick am Raspi, auf den die history ihre Daten ablegt, ist defekt
• Sticküberprüfung mit

sudo e2fsck -p /dev/sdb5  (unmounted)
sudo fsck -n /dev/sdb5 (unmounted)

lief ohne Fehler durch, Stick scheint ok zu. Das allerdings sagt nix über die Konsistenz der DB aus.

• Einen Zusammenhang zwischen Mount-Problem und DB-Problem kann ich nicht herstellen
• zweiten USB-Stick gemounted und die history jahrgangsweise auf den 2. USB-Stick kopiert, im Anschluss jeweils ein BackUp.
• in 2025 wurde ein DP (json-file) als fehlerhaft gemeldet, file gelöscht da nicht mehr relevant
• danach fehlerfreies kopieren der 2025er Ordner

Abschlusstests (alle Backups automatisch):

• sowohl von der bisherigen DB-Quelle, als auch vom 2. USB-Stick (eine Kopie der history) klappt ein BackUp ohne Fehler
• ein Backup sowohl zum USB-Stick am NAS als auch zur Festplatte des NAS als Sicherungsziel laufen ohne Fehler durch.
• Der USB-Stick selbst, als auch das Dateisystem (NTFS vs. ext4) waren offenbar nicht Ursache für Mountfehler
• Möglich also, dass das fehlerhafte json file Ursache allen Übels war.

Damit sollte morgen früh um 06:00 Uhr ein planmäßiges BackUp fehlefrei durchlaufen.

BTW:
Beim manuellen Backup wurde ich stutzig:
Zunächst prüft BackItUp offenbar, ob das Ziel gemountet ist, wenn ja versucht er umount. Dann meldet das Log, dass 2 minuten gewartet wird. Das aber ist nicht der Fall, BackItUp macht gleich weiter, was dann zu weiteren Problemen führt.

Der DB-Fehler führte nach Beobachtung offenbar dazu, dass das Ziel nicht mehr ausgehängt wurde (Grund: laufender Prozess?).

[Thomas Braun]

@Rico-Sander sagte:

Zunächst prüft BackItUp offenbar, ob das Ziel gemountet ist, wenn ja versucht er umount. Dann meldet das Log, dass 2 minuten gewartet wird. Das aber ist nicht der Fall, BackItUp macht gleich weiter, was dann zu weiteren Problemen führt.

Mach ein Issue bei GitHub auf. Muss sich @simatec wohl dann mal anschauen.

[Rico Sander]

@Thomas-Braun

Hier noch das Log zu dieser Geschichte.
Issue:
Da ich keinen GitHub Account habe, könnte das bitte Jemand für mich übernehmen?
Danke...

gui Backup gestartet ...
09:15:58.516 DEBUG mount
                   mount activ... umount is started before mount!!
09:15:58.557 DEBUG
                   mount  device is busy... wait 2 Minutes!!
09:16:08.503 DEBUG mount  cifs-mount command: "sudo mount -t cifs -o username=xxx,password=****,domain=DISKSTATION,rw,forceuid,uid=iobroker,forcegid,gid=iobroker,file_mode=0777,dir_mode=0777,vers=3.1.1 //192.168.178.3/usbshare1/iobroker_backup /opt/iobroker/backups"
09:16:08.559 DEBUG mount first mount attempt with smb option failed. try next mount attempt without smb option ...
09:16:08.618 ERROR mount [undefined Error: Command failed: sudo mount -t cifs -o username=Peter,password=****,domain=DISKSTATION,rw,forceuid,uid=iobroker,forcegid,gid=iobroker,file_mode=0777,dir_mode=0777 //192.168.178.3/usbshare1/iobroker_backup /opt/iobroker/backups
                   mount error(16): Device or resource busy
                   Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)
09:16:08.656 DEBUG mount Error: Command failed: sudo mount -t cifs -o username=Peter,password=****,domain=DISKSTATION,rw,forceuid,uid=iobroker,forcegid,gid=iobroker,file_mode=0777,dir_mode=0777 //192.168.178.3/usbshare1/iobroker_backup /opt/iobroker/backups
                   mount error(16): Device or resource busy
                   Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)

[Meister Mopper]

@Rico-Sander sagte:

Any idea?

Ich hatte dieses Phänomen mit meiner Synology auch. Vielleicht hilft dir meine Lösung.

Die Syno geht in sleep, dann benötigt sie eine wakeup.

Ich habe es mit einem crontab eingerichtet, und seitdem laufen alle Backups zuverlässig.

# NAS Wake-Up 2 Minuten vor dem 21:13 Backup
10 21 * * * ls -l /mnt/backup > /dev/null 2>&1
thomas@pbs:~$

[Rico Sander]

@Meister-Mopper
Danke für den Tipp. Sollte das Problem erneut anhängig werden, werde ich das mal probieren.
Andererseits hatte ich vor einiger Zeit, als der Fehler sporadisch schon mal auftauchte, alle Platten durchlaufen lassen (kein Ruhezustand). Das hat wohl zwar keinen Einfluss auf die Sticks an der Syno, wollte dies aber als Fehlerursache ausschließen.

Da ich aber aus anderen Gründen die aktuelle Leistung der Syno logge und im Diagramm darstelle, konnte ich zu den BackUp-Zeiten nur Aktivität sehen, keinen relativen Ruhezustand. Würde das somit im gegenständlichen Fall ausschließen.

Aber wer weiß...

Jedenfalls schön, dass Du Dich noch gemeldest hast.