Nachdem ich ein Upgrade von Linux Mint 20.3 (basierend auf Ubuntu 20.04) auf 22.02 (basierend auf Ubuntu 24.04) machte, hatte ich plötzlich ein Problem mit dem mounten meiner NAS Partitionen. Beim booten dauerte es ewig lange, bis ich mich endlich einloggen konnte. Wenn ich das mounten während des Bootvorgangs deaktivierte, führte dies wieder zu einem schnellen Bootvorang – doch wenn ich  direkt nach dem Login mounten wollte, hatte ich das selbe Timeout von fast 2 Minuten…. Wartete ich nach dem Login jedoch länger und versuchte erst so nach 5 Minuten zu mounten, funktionierte es problemlos und schnell.

Ich dachte zuerst, das Problem lag am mounten selber, weshalb ich sehr lange daran herumdokterte. Bis ich die Logfiles nochmals genauer studierte und dabei sind mir folgende Zeilen aufgefallen:

2025-11-27T11:13:35.738736+01:00 TESLINA systemd-networkd-wait-online[914]: Timeout occurred while waiting for network connectivity.
2025-11-27T11:13:35.740846+01:00 TESLINA systemd[1]: systemd-networkd-wait-online.service: Main process exited, code=exited, status=1/FAILURE

Das seltsame dabei, während dem Versuch zu mounten gab es wohl ein Network Timout, aber gleichzeitig konnte ich problemlos im Netz surfen. Wie kann das sein?


Das Problem liegt NICHT bei CIFS, sondern bei der Network-Online-Erkennung von Ubuntu/Mint.

Dadurch verzögern sich:

  • das Login

  • systemd

  • ALLE Mounts (auch systemd-Mounts)

  • und CIFS blockiert zusätzlich, weil es ohne „Network Online“ gar nicht erst startet

Das erklärt auch zu 100 % dieses Verhalten:

  • direkt nach dem Start → lange Wartezeit + Timeout → CIFS mount geht nicht

  • 5 Minuten später → System ist „online“ → CIFS mount sofort

Es existieren also zwei parallele Probleme:

  1. NetworkOnline(target) ist defekt / funktioniert bei WLAN nicht richtig

  2. CIFS wartet auf NetworkOnline(target) → daher → Timeout → Mount dauert ewig

Ursache

Linux Mint 22.2 (Ubuntu 24.04 Base) verwendet:

  • NetworkManager für WLAN

  • aber systemd wirft zusätzlich systemd-networkd-wait-online.service an
    → obwohl networkd gar nicht aktiv ist

➡️ systemd wartet vergeblich auf ein Netzwerk, das von einem anderen Dienst gemanagt wird.
➡️ nach 120 Sekunden kommt ein Timeout
➡️ erst danach wird NetworkOnline.target erreicht
➡️ erst danach mountet CIFS

Das ist exakt das, was du siehst.

Lösung: systemd-networkd-wait-online deaktivieren

Das ist die korrekte Fix-Methode für Ubuntu/Mint mit NetworkManager + WLAN.
Man kann systemd-networkd-wait-online gefahrlos deaktivieren.
NetworkManager übernimmt das vollständig.

Führe aus:

sudo systemctl disable systemd-networkd-wait-online.service
sudo systemctl stop systemd-networkd-wait-online.service

Prüfen:

systemctl status systemd-networkd-wait-online.service

Es muss stehen:

Loaded: masked (disabled; vendor preset: enabled) Active: inactive (dead)

👆 Danach wird der Boot sofort NetworkOnline.target erreichen (über NetworkManager), ohne 2-Minuten-Timeout.

Zusätzlich maskieren (empfohlen)

sudo systemctl mask systemd-networkd-wait-online.service

Damit startet es nie wieder, egal was andere Dienste wollen.

Test: Netzwerk-“Online” prüfen

Nach einem Reboot:

systemctl status network-online.target

Sollte innerhalb von < 1 Sekunde aktiv sein.

Nach dem Reboot kann man sonst noch das hier ausführen

systemd-analyze blame

und wir sehen, ob der Start jetzt sauber und schnell ist.

Oder einfach

dmesg

Hier kann man ebenfalls die Timouts sehen.

 

Ergebnis

Nach diesem Fix passiert folgendes:

  • der Desktop lädt sofort

  • CIFS systemd-Mounts starten ohne künstliche Verzögerung

  • Nemo kann sofort auf die Shares zugreifen

  • die Mounts funktionieren beim ersten Zugriff

  • mount -a funktioniert auch direkt nach Login sofort

  • Bootzeit wird von ~2:30 min → ~20 Sekunden reduziert

Warum CIFS überhaupt NetworkOnline braucht

CIFS blockiert sonst gern das gesamte Booten, sobald der Server nicht erreichbar ist.

Darum verwendet systemd:

After=network-online.target 
Wants=network-online.target

Wenn aber NetworkOnline.target selbst kaputt ist, dann hängt CIFS.

Erklärung

Warum systemd-networkd-wait-online.service aktiv ist – obwohl du NetworkManager nutzt

Ubuntu (und somit Mint) verwenden zwei verschiedene Netzwerk-Stacks parallel:

  • NetworkManager für Desktop-Nutzer

  • systemd-networkd ist trotzdem installiert und manche Services hängen daran

  • systemd-networkd-wait-online wird trotz NetworkManager gestartet

Das führt auf vielen Systemen dazu, dass:

  • systemd-networkd kein einziges Interface verwaltet

  • aber wait-online 120 Sekunden auf eine Verbindung wartet, die niemals kommen kann

  • → Timeout

  • → alle Dienste, die auf network-online.target warten, verschieben sich

  • → CIFS-Mounts warten verzweifelt, obwohl WLAN längst funktioniert

  • → dadurch die 2-minütigen Boot- oder Mount-Hänger

Das ist ein documented bug im systemd-Stack seit Ubuntu 20.04, der bis heute (24.04) weiterbesteht.

Warum Internet funktioniert, aber Mounts nicht

NetworkManager bringt Online-Connectivity, aber
systemd-networkd-wait-online prüft nicht die echte IP, sondern:

  1. existiert irgendein Interface, das systemd-networkd verwaltet?

  2. hat dieses Interface einen Carrier?

  3. hat es eine IP?

Da systemd-networkd in meinem Fall NICHTS verwaltet, bleibt Punkt 1 → nein → 120 Sekunden Timeout.

Mounts mit:

After=network-online.target 
Wants=network-online.target

werden dennoch blockiert, weil network-online.target erst nach dem Timeout erreicht wird.

Wie sorgt systemd dann dafür, dass die Mounts funktionieren?

NetworkManager hat seinen eigenen „wait-online“-Dienst:

NetworkManager-wait-online.service

Dieser ist wesentlich schneller (typisch < 1 Sekunde) und versteht WLAN korrekt.