NoMachine | Error is 5: Analyse & Lösung beim Cloud-Relaying

Veröffentlicht am von
Antwort

Wer NoMachine für den Fernzugriff auf verteilte Systeme einsetzt, schätzt in der Regel die Performance und die unkomplizierte Handhabung des systemeigenen NoMachine Network (Cloud Relaying). Kürzlich lief ich jedoch auf meinen Windows- und Linux-Clients systematisch in ein nerviges Problem: Sporadische Verbindungsabbrüche direkt beim Handshake, verbunden mit der Fehlermeldung:

„Could not connect to the server. Error is 5: Input/output error“

Der Fehler trat keineswegs dauerhaft auf. Manchmal ging die Verbindung beim zweiten oder dritten Versuch, manchmal brach sie direkt wieder ab. Da netzwerkseitig an den lokalen Routern keine Änderungen vorgenommen wurden, lag die Vermutung nahe, dass das Problem tiefer im Handshake oder der Socket-Behandlung des NoMachine Network Relays steckte.

Error is 5

In diesem Beitrag zeige ich, wie man dem Fehler über die NoMachine-Logfiles auf die Spur kommt, wo die Ursachen liegen und wie man die Verbindung stabilisiert.

1. Der Blick in die Logs (session.log)

Ein Blick in die Verbindungsprotokolle des NoMachine Enterprise Clients unter %USERPROFILE%\.nx\ verriet, dass der initiale TCP-Handshake zum STUN- und Relay-Server noch erfolgreich war, der eigentliche Datenstream aber unmittelbar danach abreisst:

Info: Network connection with key '...' established successfully.
1140 11876 2026-08-04 08:09:37 PlayerInstance: Close Network session with pid '11592'.
1140 11876 2026-08-04 08:09:38 PlayerInstance: Going to reconnect connection ...

Die GUI quittiert diesen abrupten Abreißer des Transport-Streams schließlich mit dem generischen Error 5 (Input/Output Error). Der übrigens gleich den Download der Logfiles mit anbietet!

2. Die Ursache: HTTPS-Fallback vs. Native Relaying Ports

Eine Rückfrage beim NoMachine Support brachte die für mich entscheidende Erkenntnis über die Funktionsweise des Cloud-Relays:

Wenn NoMachine feststellt, dass die eigenen nativen Protokoll-Ports (4040 für STUN/Signalisierung und 4060 für das Relay-Data-Tunneling) lokal blockiert oder durch Timeouts gestört werden, schaltet der Client automatisch auf ein HTTPS-Tunneling über Port 443 um.

Das HTTPS-Tunneling dient zwar als universelle Notlösung durch strenge Firewalls, ist jedoch extrem anfällig für Paketlaufzeiten, NAT-Keep-Alives und Re-Handshakes. Fällt der Client in diesen Modus, kommt es gehäuft zu Error 5-Abbrüchen. Parallel gab es serverseitig beim Relay-Provider ein temporäres Problem beim Verhandeln verwaister Node-Sessions, das vom Support behoben wurde.

3. Schritt-für-Schritt-Lösung auf Client-Seite

Damit der Client zuverlässig das native, performante Relaying nutzt und nicht in den instabilen HTTPS-Fallback abrutscht, sollten folgende Punkte abgearbeitet werden:

Schritt 1: Lokale Firewall-Regeln anpassen

Statt einzelne Port-Regeln zu pflegen, ist es bei NoMachine am saubersten, die Binaries des Clients vollständig in der Windows Defender Firewall für den ausgehenden Verkehr freizugeben. Dadurch werden auch dynamische High-Ports für UDP/TCP-Streams abgedeckt.

In der Windows Defender Firewall mit erweiterter Sicherheit (wf.msc):

  1. Eine neue Ausgehende Regel (Outbound Rule) anlegen.
  2. Regeltyp: Programm.
  3. Pfad auswählen (z. B. C:\Program Files\NoMachine Enterprise Client\bin\nxplayer.exe).
  4. Aktion: Verbindung zulassen (für Domäne, Privat und Öffentlich).

Schritt 2: Verwaiste Session-Caches bereinigen

Laufen die Client-Komponenten im User-Kontext (wie beim Enterprise Client üblich), können alte Session-Tokens zu Verwirrung beim Relay-Handshake führen.

Beende alle NoMachine-Prozesse und lösche die temporären Session-Ordner in der PowerShell:

# Alle aktiven NoMachine-Prozesse stoppen
Get-Process -Name "nx*" | Stop-Process -Force

# In das .nx Verzeichnis wechseln und temporäre Laufzeit-Ordner löschen
Set-Location -Path "$env:USERPROFILE\.nx"
Remove-Item -Path "R-*" -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item -Path "M-*" -Recurse -Force -ErrorAction SilentlyContinue

(Hinweis: R-* steht für Remote-Sessions, M-* für lokale Machine-Instanzen. Gespeicherte .nxs-Dateien und Zugangsdaten bleiben in der player.cfg).

4. Erreichbarkeit der Native Ports mit PowerShell testen

Um ohne Erraten zu prüfen, ob der Client die erforderlichen Ports 4040 und 4060 direkt im Netz erreicht, helfen zwei kurze PowerShell-Einzeiler.

Statischer Erreichbarkeitstest (Port-Check):

# Test für Port 4040 (NoMachine Network / STUN)
Test-NetConnection -ComputerName nb.nomachine.com -Port 4040

# Test für Port 4060 (NoMachine Relay Data Transport)
Test-NetConnection -ComputerName 178.162.226.135 -Port 4060

Liefert das Ergebnis TcpTestSucceeded : True, ist der Netzwerkpfad frei.

Dynamischer Live-Test während des Verbindungsaufbaus:

Während in NoMachine eine Verbindung aufgebaut wird, lässt sich mit folgendem Befehl live auslesen, über welchen Port gestreamt wird:

Get-NetTCPConnection -State Established | Where-Object { $_.RemotePort -in 4040, 4060, 443 } | Format-Table LocalAddress, RemoteAddress, RemotePort, State
  • RemotePort 4040 / 4060: Perfekt. Der Client nutzt das native NoMachine-Protokoll.
  • RemotePort 443: Der Client hängt weiterhin im HTTPS-Fallback fest.

Fazit

Der Error 5 in NoMachine ist oft kein Zeichen eines defekten Zielsystems, sondern ein Symptom für ein fehlschlagendes Tunneling über das Cloud-Relay. Sobald die ausgehenden Ports 4040 und 4060 in der lokalen Firewall explizit freigegeben sind und verwaiste Session-Caches aufgeräumt wurden, läuft die Verbindung wieder gewohnt stabil und performant.

Lancom Wallmount: Router-Gehäuse ohne Schlüssel öffnen

Veröffentlicht am von
Antwort

Zugegeben, dieser Beitrag ist etwas ungewöhnlich – aber manchmal schreibt die Praxis eben ihre eigenen Geschichten.

Am letzten Wochenende musste ich einen LANCOM 1793VA-4G von Vodafone auf die Telekom umstellen. Nach 140 km Anfahrt zum Standort stand ich vor dem eigentlichen Problem: Der Schlüssel für das Schloss, mit dem der Router im Wallmount gesichert ist, war nirgends auffindbar.

Gesichert war die Verriegelung mit einem kleinen ABUS 65/15 Messingschloss. Da ich generell nie ohne vernünftiges Werkzeug unterwegs bin, stellten sich mir folgende Handlungsoptionen:

  1. Kontakt mit dem Kunden aufnehmen: Nachfragen, wo denn der Schlüssel sein könnte
  2. Fahrt in den Baumarkt: Um eine große Kneifzange oder Bolzenschneider zu besorgen
  3. Die vorhandene Kneifzange aus meinem Werkzeugkoffer ausprobieren

Option 1) war natürlich der erste und sinnvollste Schritt. Da der Verbleib des Schlüssels jedoch völlig unklar war, fiel die Wahl auf Option 3).

Knipex 160mm Kneifzange

Ich kann hiermit bestätigen: Für eine 160mm Kneifzange stellt das Schloss kein wirkliches Hindernis dar. Der Trick dabei ist: Nicht versuchen, den Bügel auf einmal mittig durchzuzwicken, sondern sich mit zwei oder drei gezielten Schnitten durch das Messing zu arbeiten.

Die eigentliche Umstellung – der Wechsel von Vodafone zur Telekom und damit zu fast der doppelten Bandbreite – funktionierte danach völlig problemlos. 🙂

Enjoy it, b!

NoMachine | „The session negotiation failed“

Veröffentlicht am von
Antwort

Error: Cannot create a new display, please contact your system administrator

In einem speziellen Kundenumfeld darf ich öfters mit NoMachine arbeiten und ich finde das Zeug echt cool!

Nun hatte ich beim Zugriff auf einen Linux Host (Linux Mint 22.3 mit Xfce) das folgende Problem.

Die Fehlermeldung hatte ich ja bereits eingangs gepostet; das Problem konnte ich jedoch durch die folgenden beiden Befehle lösen:

# bash
sudo /etc/NX/nxserver --addtoredis
sudo /etc/NX/nxserver --restart

Danach lief es wieder, wie schon einige Jahre zuvor 🙂

Enjoy it, b!

Fedora Workstation 44 | „The final workaround“ für die Maus

Veröffentlicht am von
Antwort

Einleitung

In diesem Beitrag hatte ich die Microsoft Bluetooth Mouse 3600 unter Fedora 44 wieder zum Laufen gebracht.

Irgendwie halt … und zunächst funktionierte sie auch ganz gut, bis ein System-Update von Fedora 44 notwendig war und dazu GNOME die Version 50.1 erreichte. Danach Schluss mit lustig und ich musste einige Zeit mit einer Cherry Wirless Maus arbeiten, was mir schon wegen der wenigen Ports am Surface Laptop nicht wirklich gefallen hat.

Nach einem Neustart war sie zwar „connected“… aber komplett tot. In den Settings / Bluetooth wurde die Maus meistens mit einer “Connection” angezeigt, wollte sich aber trotzdem nicht zum Arbeiten überreden lassen.

Der entscheidende Test

sudo systemctl restart bluetooth

→ nach wenigen Sekunden funktioniert die Maus wieder. Die Ursache scheint zu sein, dass der Bluetooth Controller beim Start in einen inkonsistenten Zustand kommt. Die Verbindung steht, aber HID-Stack ist nicht aktiv.

Die mögliche Lösung

Der Test unten (restart des Bluetooth-Stacks) brachte die Maus zurück.

bluetoothctl power off
sleep 2
bluetoothctl power on

Damit war die Grundlage für das Script gefunden und der ehemalige Ansatz konnte entsprechend umgebaut werden.

Finales Script – bt-mouse-heal-prod.sh

Damit die Sache nicht zu kompliziert wird, hier die notwendigen Scripte als ZIP-Datei.

Das eigentliche Health-Script, bt-mouse-heal-prod.sh:


#!/usr/bin/env bash
set -Eeuo pipefail

DEVICE_NAME="${DEVICE_NAME:-BluetoothMouse3600}"
DEVICE_PREFIX="${DEVICE_PREFIX:-F1:00:85:}"
MAX_RETRIES="${MAX_RETRIES:-6}"
BTCTL_TIMEOUT="${BTCTL_TIMEOUT:-10}"
RESET_ONCE="${RESET_ONCE:-true}"
DEBUG="${DEBUG:-false}"

RUNDIR="${XDG_RUNTIME_DIR:-/tmp}"
LOCK_FILE="${RUNDIR}/bt-mouse-heal.lock"
RESET_STAMP="${RUNDIR}/bt-mouse-reset.stamp"
TAG="bt-mouse-heal"

log() {
  [[ "$DEBUG" == "true" ]] || return 0
  printf '[%s][DEBUG] %s\n' "$TAG" "$*" >&2
}

btctl() {
  timeout "$BTCTL_TIMEOUT" bluetoothctl "$@" 2>&1 || true
}

is_connected() {
  btctl info "$1" | grep -qi 'Connected: yes'
}

find_mac_by_name() {
  btctl devices Paired | awk -v name="$DEVICE_NAME" -v pfx="$DEVICE_PREFIX" '
    /^Device[[:space:]]+[0-9A-Fa-f:]{17}[[:space:]]+/ {
      mac=$2
      dev=$0
      sub(/^Device[[:space:]]+[0-9A-Fa-f:]{17}[[:space:]]+/, "", dev)
      if (dev==name && toupper(substr(mac,1,length(pfx)))==toupper(pfx)) {
        print mac; exit
      }
    }'
}

ensure_agent() {
  btctl power on >/dev/null
  btctl agent on >/dev/null
  btctl default-agent >/dev/null
}

controller_soft_reset() {
  log "Reset bluetooth controller"
  btctl power off >/dev/null
  sleep 2
  btctl power on >/dev/null
  sleep 3
}

connect_with_retries() {
  local mac="$1"
  ensure_agent
  btctl trust "$mac" >/dev/null

  for i in $(seq 1 "$MAX_RETRIES"); do
    is_connected "$mac" && return 0
    btctl connect "$mac" >/dev/null
    sleep "$i"
    is_connected "$mac" && return 0
  done
  return 1
}

main() {
  exec 9>"$LOCK_FILE"
  flock -n 9 || exit 0

  if [[ "$RESET_ONCE" == "true" ]]; then
    [[ -f "$RESET_STAMP" ]] || {
      controller_soft_reset
      touch "$RESET_STAMP"
    }
  else
    controller_soft_reset
  fi

  mac="$(find_mac_by_name || true)"
  [[ -z "$mac" ]] && exit 2

  connect_with_retries "$mac" && exit 0

  controller_soft_reset
  mac="$(find_mac_by_name || true)"
  connect_with_retries "$mac"
}

main "$@"

systemd Integration

systemd-Service


[Unit]
Description=Heal Microsoft Bluetooth Mouse 3600 connection (RPA-safe)
After=graphical-session.target
Wants=graphical-session.target

[Service]
Type=oneshot
ExecStart=%h/.local/bin/bt-mouse-heal.sh
Environment=DEVICE_PREFIX=F1:00:85:
Environment=DEVICE_NAME_REGEX=BluetoothMouse3600

systemd-Timer


[Unit]
Description=Heal Microsoft Bluetooth Mouse 3600 connection (RPA-safe)
After=graphical-session.target
Wants=graphical-session.target

[Service]
Type=oneshot
ExecStart=%h/.local/bin/bt-mouse-heal.sh
Environment=DEVICE_PREFIX=F1:00:85:
Environment=DEVICE_NAME_REGEX=BluetoothMouse3600

Wichtig:

Die ~/.config/systemd/user/bt-mouse-heal.service und die ~/.config/systemd/user/bt-mouse-heal.timer Dateien erstellt das folgende Installations-Skript automatisch und setzt auch die Rechte passend.

Fazit

Die Sache ist kompliziert, hat aber mit dieser Lösung ein erträgliches Ende gefunden. Falls nicht, muss ich nochmals ran … aber die Hoffnung stirbt bekanntlich zuletzt und wenn man nur zwei USB-Ports am Laptop hat, lohnt sich der Fight allemal.

Enjoy it, b!

M365 | Umbenennen des lokalen Ordners für OneDrive for Business

Veröffentlicht am von
Antwort

OneDrive for Business (O4B) erstellt unter Windows einen Ordner im Benutzerprofil nach dem Schema „Onedrive – <Firmenname>“. Wurde bei der Einrichtung des M365-Tenants einfach der Firmenname verwendet, und war dieser lang können daraus eine Reihe von Problemen entstehen, bis hin zur Überschreitung der maximalen Pfadlänge von 260 Zeichen unter Windows.

Das Problem stellt sich konkret wie folgt (der Name selbst wurde geändert, aber die Länge ist identisch mit dem, was mir vorgegeben wurde):

Zwar ließe sich die enorme Breite des Pfadnamens zweckentfremden, um die Seitenleiste im Windows Explorer künstlich aufzuspannen, doch war dies kaum die Intention der Administration. Es drängt sich vielmehr die Frage auf, ob die Auswirkungen eines derart langen Tenant-Namens bei der Einrichtung überhaupt bedacht wurden.

Die Anforderung

Der Pfad im Benutzerprofil sollte sinnvoll gekürzt werden. Schnell einigte man sich auf den Namen „Praxis“ und damit sieht der Pfad nun wie folgt aus.

Da ich selbst ein Verfechter kurzer Pfade bin, hier ein Tipp für kleinere Unternehmen: Man könnte im Benutzerprofil auch einfach die Initialen der Mitarbeiter nutzen. Das Ergebnis sähe dann so aus:

Bevor wir uns in Details verlieren: Zurück zum eigentlichen Thema. Um das Problem in den Griff zu bekommen, gibt es zwei Lösungswege.

Änderung des Namens im Microsoft Entra Admin Center

Die Änderung greift für alle OneDrive-Nutzer. Einzige Voraussetzung: Die Benutzer müssen ihr Konto einmalig neu verknüpfen (Relink), damit der neue Pfad übernommen wird..

Das sieht dann wie folgt aus und man navigiert über Übersicht / Eigenschaften zum Namen der dann geändert werden kann (Speichern dabei nicht vergessen).

Für die Ungeduldigen unter uns: M365 benötigt dazu 24h und machmal noch einen Tick länger, also bitte warten!

Änderung des OneDrive-Namens mit PowerShell

Falls eine globale Namensänderung nicht gewünscht ist, lässt sich die Benennung von O4B auch individuell für einzelne Benutzer anpassen. Wie so oft hilft hier ein wenig PowerShell-Magie – allerdings gibt es dabei ein paar Fallstricke zu beachten.

  • Man muss das OneDrive for Business schon konfiguriert haben (sonst sind die notwendigen Einträge in der Registry und im Dateisystem nicht vorhanden)
  • Es dürfen KEINE Ordner umgeleitet sein, falls man das gemacht hat bitte wieder deaktivieren und den endgültigen Sync abwarten

Danach kann man das Skript (nach Anpassung der Variablen) verwenden. Wichtig dabei ist, dass der Ordner immer mit „OneDrive – …“ benannt wird, also hier nur den Shortname ändern.

Der Name ist nun kürzer. Ein kleiner Fallstrick bleibt: Wenn das Backup der Standardordner noch aktiv war, geistern die alten Pfadnamen oft weiter im Benutzerprofil herum. Hier sollte man vorab sicherstellen, dass die Synchronisation sauber getrennt wurde.

Enjoy it!

Fedora Workstation 44 | Jetzt will die Maus garnicht mehr

Veröffentlicht am von
1

Manche Hardware funktioniert einfach, die Microsoft Bluetooth Mouse 3600 unter Fedora 44/GNOME 50 gehört leider nicht dazu. Während sie am Surface Laptop 3 unter Windows jahrelang perfekt lief, war der Umzug auf Linux für das ‚Mausi‘ der Anfang vom Ende. Das Pairing mit Bluetooth wurde stetig schlechter, bis sie mit dem Upgrade auf Fedora 44 nun komplett unbrauchbar geworden ist.

Man muss dazu wissen, dass der mit Fedora 44/GNOME 50 eingeführte Bluetooth-Stack eine gewisse Zurückhaltung gegenüber BLE-HID-Geräten zeigt, was häufig zu Verbindungsproblemen führt.

Eine kurze Beschreibung des Problems

  • Nach dem Upgrade verbindet die Maus nicht mehr automatisch
  • Manuelles Pairing funktioniert, aber nur mit Geduld
  • Und die MAC‑Adresse der Maus wechselt fröhlich hin und her1

1) und ja, auch Bluetooth-Mäuse haben eine MAC-Adresse

Zeit also, der Sache auf den Grund zu gehen, bevor ich die Anschaffung einer neuen Maus überhaupt in Erwägung ziehe. Man ist ja irgendwo auch Schwabe 😉

Das Sympton ist, die Maus wird angezeigt aber Linux tut so als ob es eine neue wäre

Nach dem Upgrade auf Fedora 44 zeigt bluetoothctl folgende Info an:

Device F1:00:85:92:CA:34 (random)

Die Maus meldet sich mit wechselnden BLE‑Adressen. Das ist normal, nennt sich „Resolvable Private Address“ RPA . BlueZ erkennt solche Geräte über einen Identity Resolving Key (IRK). Wenn der IRK fehlt, denkt Fedora bei jeder neuen Adresse: „Noch nie gesehen …“ und das Theater geht los.

Das erklärt, warum AutoConnect nicht funktioniert, obwohl die Maus korrekt gepairt ist.

Die Ursache liegt in einem blockierten AutoConnect vor der Anmeldung

Mit GNOME 50 (und der damit einhergehenden Entwicklung in den zugrunde liegenden Bibliotheken wie bluez) wurde das Sicherheitsmodell für Bluetooth verschärft. BLE-HID-Geräte (wie die Mouse 3600) benötigen oft einen aktiven Austausch von Schlüsseln beim Reconnect. Wenn der Agent der User-Session noch nicht aktiv ist, schlägt dieser Austausch fehl oder wird vom System ignoriert, um unautorisierte Verbindungen auf Hardware-Ebene zu verhindern.

Letztendlich sehen wir die folgenden Syptome:

  • kein AutoConnect beim Boot von Linux
  • manueller Connect funktioniert (bei Fedora 44 auch nicht immer und davor doch recht zuverlässig) oft erst nach 60 bis 120 Sekunden
  • Zur Verbindung muss eine User-Session vorhanden sein

Der erste Schritt ist, dass wir mit der Maus ein neues Pairing durchführen müssen:

bluetoothctl
remove <DEVICE-MAC>
scan on
pair <DEVICE-MAC>
trust <DEVICE-MAC>
connect <DEVICE-MAC>

Schauen wir uns aber die info-Datei für die Maus an, so sind nach einen korrekt erfolgtem Pairing alle notwendigen Einträge vorhanden.

# Speicherung der Bluetooth-Informationen der Maus in der info
/var/lib/bluetooth/<ADAPTER-MAC>/<DEVICE-MAC>/info

Die Datei beinhaltet alle notwendigen Informationen wie den IRK, LTK und HID-Services.

Wir merken uns:

  • ADAPTER-MAC = Hardware-Adresse des Bluetooth-Controllers im Laptop (die ist und bleibt statisch)
  • DEVICE-MAC = Hardware-Adresse der Maus (Device), die sich in Grenzen dynamisch verhält

Den Pfad oben bauen wir als wie folgt zusammen, und dazu wechseln wir der Einfachheit halber in den interaktiven Sudo (wer in diesem verbleibt, spart sich in den kommenden Konfigurationen das nervige tippen von Befehl und Passwort):

# Wechsel in den interaktiven sudo-Modus
sudo -i

Am einfachsten (und damit ohne Tipp-Fehler), lassen sich Verzeichnispfade mit ls und der TAB-Taste verwenden:

# Dazu ls und TAB für die Expansion des folgenden Pfads verwenden
#- wichtig ist, dass die MAC-Adresse des Controllers bei Euch anders heißt!
ls '/var/lib/bluetooth/F0:1D:BC:9C:AC:9D'

Hängen wir dann an diesen Pfad die DEVICE-MAC mit an, können wir im Verzeichnis die info-Datei der Microsoft Bluetooth 3600 finden.

Damit ist die technische Basis gelegt.

Die zweite Baustelle sind die wechselnden MAC-Adresse der Maus (DEVICE-MAC)

Die Microsoft Maus nutzt Adressen, die immer mit F1:00:85: beginnen. Der Rest ändert sich.
BlueZ erkennt die Maus über den IRK, aber GNOME 50 leider nicht zuverlässig.

Das Problem konnte mit einer udev-Regel, die hilft den Connect auszulösen, sobald die Maus auftaucht, gelöst werden.

Die Sache wird nun als dritter Schritt an systemd übergeben und dort in eine Regel gepackt

# udev-Regel erstellen
sudo nano /etc/udev/rules.d/99-bt-mouse-autoconnect.rules

# Inhalt der Regel
ACTION=="add", SUBSYSTEM=="bluetooth", ATTR{address}=="F1:00:85:*", RUN+="/usr/bin/bluetoothctl connect %E{address}"

Genau genommen arbeitet die Regel die folgenden Aufgaben ab:

  • Sie reagiert auf jedes Bluetooth‑Gerät, dessen Adresse mit F1:00:85: beginnt
  • %E{address} übergibt die aktuelle (random) MAC an bluetoothctl
  • GNOME 50 wird komplett umgangen
  • Die Maus verbindet sobald sie auftaucht

Die Regel sollte automatisch ausgeführt werden und damit blieb nur der Weg das mit einem systemd-Service um GNOME „herumzubauen“ (zumindest habe ich keine andere Möglichkeit gefunden).

Damit umschiffen wir die folgenden Problemzonen:

  • GNOME‑Agent‑Blockade
  • Race‑Condition beim Login
  • 60–120‑Sekunden‑Timeout
  • verzögerten BLE‑Reconnect

Der funktionierende systemd-AutoConnect-Service:

# Als erstes muss der Service angelegt werden
sudo nano /etc/systemd/system/bt-mouse-autoconnect.service

# Und der Service in der Config definiert werden
[Unit]
Description=Auto-connect Bluetooth Mouse after GNOME startup
After=graphical.target bluetooth.service
Wants=bluetooth.service

[Service]
Type=oneshot
ExecStart=/usr/bin/bluetoothctl connect F1:00:85:93:CA:34
ExecStart=/usr/bin/sleep 2
ExecStart=/usr/bin/bluetoothctl connect F1:00:85:93:CA:34

[Install]
WantedBy=graphical.target

Das Timing im Logon-Prozess ist nicht ganz optimal, darum probiert es der Service mit dem Start nach 2s ein zweites Mal.

Zum Schluss fehlt nur noch die Aktivierung des Service verbunden mit einem Neustart:

# Aktivierung des Service
sudo systemctl daemon-reload
sudo systemctl enable bt-mouse-autoconnect.service

# Reboot
sudo reboot

Fazit

Die Maus läuft und ich muss keine neue mehr besorgen, zumal ich die Teile immer sehr mochte da sie wirklich robust und zuverlässig waren sind. Auch wenn ich mich erneut an dem Surface Laptop anmelde, ist die Maus nach ca. 30 Sekunden da. Man könnte hier sicherlich noch eine Reihe von Optimierungen und Retries bauen, ich will es aber dabei belassen. Wie sagt der Schwabe gerne „für me duats des“ … und er ist glücklich, muss er doch keine neue Maus kaufen.

Enjoy it, b!

Upgrade | Fedora Workstation 44

Veröffentlicht am von
Antwort

Ende April war es wieder so weit: Eine neue Fedora-Version stand vor der Tür. Mein bewährter Surface Laptop 3 wartete bereits auf das Upgrade auf die Version 44. Doch diesmal lief der Prozess über die Shell nicht ganz so reibungslos durch, wie ich es gewohnt war. Ein Paketkonflikt im Bereich des Power-Managements stoppte das Vorhaben abrupt.

Das Problem waren die Pakete für das Power-Management

Beim Versuch, das Upgrade einzuspielen, brach DNF mit einer Fehlermeldung ab. Der Kern der Nachricht: Dateikonflikte zwischen tlp und tuned-ppd. Beide Pakete versuchten, dieselben DBus-Service-Dateien unter /usr/share/dbus-1/ zu beanspruchen.

Hier der Fehler im Detail:

Fedora hat mit Version 44 den Wechsel hin zu tuned als Standard-Daemon für Stromsparprofile vollzogen. tuned-ppd dient dabei als Schnittstelle, damit die GNOME-Einstellungen (der Schieberegler für „Leistung/Ausbalanciert/Energiesparen“) weiterhin funktionieren. Wer – wie ich – in der Vergangenheit manuell TLP installiert hat, um das Maximum aus dem Akku des Surface herauszuholen, gerät hier in einen harten Ressourcenkonflikt.

Die Lösung war die Deinstallation von TLP

Da Fedora 44 nun massiv auf tuned setzt, habe ich mich dazu entschieden, TLP den Laufpass zu geben und auf den neuen Standard zu setzen. Damit war der Weg für das Upgrade frei.

Folgende Schritte in der Shell haben das Problem gelöst und beschreiben dazu noch das Upgrade:

Die Befehle und Fehlermeldungen findet ihr in dieser Datei, aber bitte nur Schritt für Schritt ausführen.

Nach dem Upgrade ist vor dem Upgrade …

Was mir sonst noch aufgefallen ist (nach dem Upgrade):

Das bisher verwendete Hintergrundbild stammte noch aus Fedora 43 und wurde beim Upgrade entfernt. Daher musste ich ein neues Wallpaper aus dem Fedora‑44‑Paket auswählen.

Die OneDrive‑Integration schlug wiederholt fehl. Erst nach dem vollständigen Entfernen der bestehenden Verbindung und einer neu erforderlichen App‑Registrierung über GNOME konnte die Synchronisation wiederhergestellt werden

Fedora Workstation verwendet aktuell noch den 6er‑Kernel. Das ist jedoch kein Nachteil – das System läuft stabil, wie schon seit langer Zeit.

Fazit

Wieso es genau zu diesem Konflikt kam? Wahrscheinlich habe ich in Fedora 43 zu intensiv an den Energieeinstellungen optimiert und dabei TLP als Ergänzung oder Ersatz installiert. Da Fedora 44 nun eine eigene, moderne Architektur für diese Profile mitbringt (tuned-ppd), vertragen sich die beiden Ansätze auf Dateiebene nicht mehr.

Nach dem Reboot lief mein Surface Laptop 3 anstandslos unter Fedora 44 hoch. Wer also vor einem ähnlichen „Transaction failed“ steht: Prüft eure installierten Power-Management-Tools und werft einen Blick auf die Gnome-Extensions, nicht alle waren zum Start von Fedora 44 kompatibel.

No Panic please!

Ja, nein, vielleicht — und bevor ich mich weiter in dieser Antwortmatrix verliere, schreibe ich jetzt einfach ein paar Sätze. Dieser Blog hier nennt sich Windows SBS und Essentials Blog, und genau so ist er im Mai 2008 gestartet. Der erste Beitrag? Natürlich ein Defekt des CPU‑Lüfters in einem Lexmark X502n Multifunktionsdrucker. Ein würdiger Auftakt für eine lange Reise voller Themen, die streng genommen alle aus dem Small‑ und Medium‑Business‑Umfeld stammen. Und ja: Ich dachte damals, das könnte vielleicht irgendjemandem helfen.

Zur Überraschung: Hat es und tut es immer noch, auch wenn sich die KI an den Themen sattfrist und 50% der Hits weggefallen sind.

Den eigentlichen Windows Small Business Server (SBS) und seinen Nachfolger, den Windows Server 2012 Essentials (SBE), hat uns Microsoft dann genommen — in der charmanten Annahme, kleine Firmen würden natürlich alle in die Cloud wechseln.

Spoiler: Das war gleichzeitig richtig und komplett daneben. Die Chance, Exchange aus den Kellern der Kunden zu befreien und in kompetente Hände zu legen, konnte ich mir jedenfalls nicht entgehen lassen. Also habe ich ASAP eine Menge Migrationen von Exchange (SBS 2008 R2) nach BPOS durchgeführt. Und obwohl ich im Enterprise‑Bereich schon einige Exchange‑Wiederherstellungen überlebt hatte, wollte ich mir diesen Nervenkitzel bei kleinen Kunden nicht mehr antun. Man wird ja nicht jünger. Zusätzlich gibt es im SMB-Umfeld eine Reihe von LOB-Anwendungen die ein wahres Horrorkabinet darstellen … und während die Hyperscaler an die Cloud denken, kämpfe ich mit „lokalen Admins“ damit die Praxissoftware überhaut läuft!

Linux und ich — das ist übrigens keine Beziehung, die erst begann, als virtuelle Router plötzlich „hip“ wurden oder eine SSH‑Session auf ein Synology‑NAS die Tür zu erweiterten Konfigurationen (oder nennen wir es ruhig „Hacks“) öffnete. Nein, Linux war mein zweiter Dateiserver nach Novell NetWare 3.1. Irgendwann in den 90ern habe ich mich — schneller als manche Großunternehmen — entschieden, im Heimnetz auf TCP/IP umzusteigen. Aus Kostengründen lief auf dem Server Linux mit einem Kernel 1.x und Samba. Der Client war bis 1996 OS/2 Warp 3, und erst dann haben Windows NT 4.0 und ich uns endlich gefunden. Eine späte, aber stabile Beziehung.

Grundsätzlich soll hier jedes Betriebssystem seinen Platz finden, das im SMB‑Umfeld sinnvoll ist und mich gelegentlich an den Rand der Verzweiflung bringt — äh, ich meine: vor interessante Herausforderungen stellt.

Darum wird es in diesem Blog auch weiterhin um Themen aus dem SMB‑Kosmos gehen. Vielleicht nenne ich ihn irgendwann sogar „Small‑ und Medium‑Business‑Blog“ oder etwas ähnlich Kreatives. Was meint ihr dazu?

Enjoy it, b!

Windows | Ablauf der Secure-Boot-Zertifikate

Veröffentlicht am von
Antwort

Es dauert nicht mehr lange und wir haben Juni und die Zertifikate für den Windows-Secure-Boot laufen aus.

Das eigentliche Problem ist …

Secure Boot ist der Schutzwall beim Systemstart. Er stellt sicher, dass nur signierte und vertrauenswürdige Bootloader geladen werden. Diese Vertrauenskette basiert auf Zertifikaten, die im UEFI (dem BIOS-Nachfolger) hinterlegt sind.

Die Krux: Die aktuell weit verbreiteten Zertifikate (wie die „Windows Production CA 2011“) laufen im Jahr 2026 aus. Da Hardware oft viele Jahre im Einsatz ist, müssen die neuen Zertifikate („Windows UEFI CA 2023“) jetzt auf die Rechner verteilt werden, damit der Übergang nahtlos funktioniert.

Sollte der Rechner keinen SecureBoot verwenden (ich kenne da einige alte Systeme mit Windows Server 2019) dann könnt ihr jetzt mit dem Lesen aufhören. Gibt es aber weitere Windows Systeme, dann vielleicht doch nicht 🙂

Glücklicherweise hat Microsoft diesmal einen klaren Plan

Microsoft geht bei diesem kritischen Update vorsichtig vor, um „Bricks“ (unbrauchbare Hardware) zu vermeiden. Der Rollout erfolgt in Phasen:

  1. Vorbereitungsphase: Die neuen Zertifikate werden per Windows Update bereitgestellt, aber noch nicht aktiv erzwungen.
  2. Testphase: Administratoren können die neuen Zertifikate manuell aktivieren (siehe PowerShell-Teil unten).
  3. Erzwingungsphase: Ab 2026 wird das neue Zertifikat zur Pflicht.

Besonders für Windows Server hat Microsoft ein „Playbook“ veröffentlicht, da hier die Ausfallrisiken bei Boot-Fehlern besonders kritisch sind.

Windows Server Secure Boot playbook for certificates expiring in 2026 | Microsoft Community Hub

Mit PowerShell kann man eine grundlegende Prüfung durchführen

Neuere Windows-Versionen zeigen den Status der Secure-Boot-Zertifikate mittlerweile direkt in der Windows-Sicherheit-App an. Doch für Administratoren, die hunderte Systeme verwalten oder eine Automatisierung benötigen, ist die PowerShell das Werkzeug der Wahl.

Ermitteln des Status

PowerShell muss für die Tests mit administrativen Rechten gestartet werden! Und bitte, den Code Zeile für Zeile ausführen und nicht als Skript betrachten. Vielleicht seit ihr ja nach Zeile 6 schon fertig.

Details zum Bootloader auslesen

Um sicherzugehen, welche Version des Bootmanagers aktuell verwendet wird, hilft dieser Befehl.

Zum Schluss (falls notwendig) kann man das Update manuell triggern

Wenn ihr nicht auf den automatischen Rollout warten möchtest (z.B. in einer Testumgebung), kannst das Update der UEFI-Variablen über die Registry und eine geplante Aufgabe erzwungen werden.

Achtung: Das Update schreibt in das UEFI des Mainboards.

Wie sieht das in der Praxis aus …

Das Windows Notebook hatte durch die Installation aller Updates die Zertifikate schon an board.

Der Fehler 0xC0000100 kommt daher, dass nicht jede Hardware das Auslesen der Detault-Datenbank des Herstellers zuläßt.

Fazit

Der Wechsel der Secure-Boot-Zertifikate ist eine Operation am offenen Herzen und bedeutet vor allem in „Altumgebungen“ einiges an Arbeit, muss doch jeder PC geprüft werden. Insofern ist jetzt ein gutes Zeitpunkt damit zu beginnen.

Enjoy it, b!

Windows 11 | April Update KB5083769, Klick mit der linken Maustaste tut nicht mehr

Veröffentlicht am von
Antwort

Nach dem April‑Update 2026 für Windows 11 berichten viele Nutzer und ich auch 🙂 über Probleme mit der Microsoft Bluetooth Mobile Mouse 3600. Typisch ist folgendes Verhalten:

  • Mauszeiger bewegt sich
  • Linke/rechte Maustaste reagieren nicht mehr
  • Maus bleibt als verbunden angezeigt
  • Problem tritt besonders nach Neustart oder Standby auf

Das Problem konnte ich inzwischen auch mit einer Logitech MX35 nachvollziehen.

Ursache

Die Mouse 3600 ist eine reine Bluetooth‑LE‑Maus ohne USB‑Dongle. Nach dem April‑Update greift Windows offenbar aggressiver auf Bluetooth‑Energiesparmechanismen zurück. Dabei werden Klick‑Events nicht mehr zuverlässig verarbeitet – obwohl die Maus verbunden bleibt.

Ein Firmware‑Update für die Mouse 3600 existiert nicht, das Problem liegt auf Windows‑Seite.

Bewährter Workaround

Der bislang zuverlässigste Fix:

  1. Geräte-Manager
  2. Bluetooth → Bluetooth‑Adapter (z. B. Intel / Qualcomm)
  3. Register Energieverwaltung
  4. Haken entfernen bei
    „Computer kann das Gerät ausschalten, um Energie zu sparen“
  5. Neustart

Zusätzlich empfohlen:
Über Windows Update → Erweiterte Optionen → Optionale Updates verfügbare Bluetooth‑Treiber installieren.

Was nicht hilft

  • Maus neu koppeln
  • Bluetooth‑Troubleshooter
  • Maus neu installieren
  • sfc /scannow

Enjoy it, b!

Windows 11 | Problem Ejecting USB Attached SCSI (UAS) Mass Storage Device

Veröffentlicht am von
Antwort

Man möchte nur schnell die externe SSD abziehen, klickt auf Hardware sicher entfernen / Eject portable device und bekommt die folgende Fehlermeldung angezeigt:

Windows behauptet, dass noch ein Programm auf das Laufwerk zugreift.

Die üblichen Verdächtigen

Häufig, aber halt nicht immer, spielen die folgenden Programme oder Prozesse eine Rolle:

  • Ein Explorer-Fenster ist noch im Verzeichnis der SSD offen
  • Die PowerShell oder Eingabeaufforderung stehen noch auf der SSD
  • Von Anwendungen geöffnete Dateien
  • Ein Virenscanner oder die Windows-Indizierung arbeitet im Hintergrund
  • Ein Kopiervorgang ist noch nicht ganz abgeschlossen

Wenn angeblich alles geschlossen ist

Ich hatte neulich den Fall, dass keiner dieser Punkte zutraf. Selbst die Einstellung auf „Schnelles Entfernen“ in den Richtlinien (ein wichtiges Thema, das ich bereits hier in einem anderen Kontext gestreift habe) war korrekt gesetzt. Eigentlich sollte das System den Schreibcache so verwalten, dass ein Auswerfen jederzeit möglich ist – theoretisch.

In der Praxis blieb die Fehlermeldung hartnäckig. Wenn also alle Anwendungen geschlossen sind und auch der Explorer keine offenen Zugriffe mehr zeigt, gibt es noch einen ganz speziellen Übeltäter der bei häufig geöffnet ist.

Der Windows Task-Manager blockiert die SSD

Es klingt fast ironisch:
Man öffnet den Task-Manager, um herauszufinden, welcher Prozess das Laufwerk blockiert – und genau dadurch verhindert man das Auswerfen.

Der Task-Manager greift zur Überwachung der Performance (Datenträgerauslastung, Antwortzeiten etc.) aktiv auf die Hardware-Informationen zu. Solange das Fenster des Task-Managers offen ist und die SSD in der Liste der Ressourcen überwacht wird, hält Windows oft ein Handle auf das Gerät offen. Schließt man den Task-Manager, kann die SSD ohne Probleme entfernt werden.

In den meisten Fällen lässt sich die SSD danach sofort und ohne Murren entfernen. Manchmal sind es eben die Werkzeuge zur Fehlersuche selbst, die der Lösung im Weg stehen.

Enjoy it, b!