Info2soft verwendet Cookies, um Ihnen ein besseres und angenehmeres Surferlebnis auf unserer Website zu ermöglichen. Datenschutzerklärung
Wird geladen...
Viele vSphere-Administratoren stoßen bei der Einrichtung der dateibasierten Sicherung des vCenter Server Appliance (VCSA) mit einer SMB-Freigabe auf den Fehler „vCenter-Sicherung: SMB nicht unterstützt“. In dieser Anleitung analysieren wir die Ursachen dieses Problems und zeigen Ihnen eine Schritt-für-Schritt-Lösung.
Häufig auftretende Fehlermeldungen:
1. Abhängigkeit von SMBv1 und dessen Außerbetriebnahme (häufigste Ursache)
Frühere VCSA-Versionen nutzten standardmäßig SMBv1, sofern SMBv2 nicht manuell aktiviert wurde. Microsoft hat SMBv1 jedoch bereits 2014 als veraltet eingestuft. Ab Windows 10 Version 1709 und Windows Server Version 1709 ist SMBv1 bei der Standardinstallation nicht mehr enthalten. Wenn der Zielserver SMBv1 ablehnt, schlägt die Protokollverhandlung fehl, und die VAMI-Oberfläche gibt den Fehler „nicht unterstützt“ aus.
2. Bekannte Fehler in bestimmten vCenter-Versionen
3. Veraltete CIFS-Einhängepunkte
Eine abgebrochene Sicherung kann verwaiste Einhänge unter /storage/remote/backup/cifs/ hinterlassen. Diese blockieren neue Sicherungsversuche und führen zu Fehlermeldungen in der VAMI.
4. Falsche Konfiguration und fehlende Berechtigungen
Anhand der folgenden Tabelle können Sie Ihre erhaltene Fehlermeldung der wahrscheinlichsten Ursache sowie der empfohlenen Lösung zuordnen. Alle Verfahren gelten für vCenter 6.7 U2+, 7.x, 8.x und VCSA-Bereitstellungen.
|
Fehlermeldung / Symptom |
Ursache |
Empfohlene Lösung |
|
„Der Speichertyp SMB wird nicht unterstützt“ |
SMBv1 auf dem Dateiserver deaktiviert |
Methode 1 (SMBv2/3 auf VCSA aktivieren) |
|
„Der SMB-Speicherort ist ungültig“ |
SMBv1 deaktiviert oder Fehler bei der Hostnamenauflösung |
Methode 1; Verwendung des FQDN prüfen |
|
„Der Pfad wurde vom entfernten Dateisystem nicht exportiert“ |
FIPS-Modus auf vCenter 7.0 U3 aktiviert |
Methode 2 (Upgrade auf 7.0 U3c oder neuer) |
|
NT_STATUS_NOT_FOUND in backup.log |
Kurzer Hostname im Sicherungsziel verwendet |
FQDN in den Sicherungseinstellungen eintragen (Methode 4) |
|
NT_STATUS_ACCESS_DENIED in den Protokollen |
Unzureichende Berechtigungen des Dienstkontos |
Vollständige Administratorrechte auf der SMB-Freigabe gewähren (Methode 4) |
|
NT_STATUS_LOGON_FAILURE nach Upgrade auf 7.0 U3h |
DFS-Namespace, Änderung der SMB-Client-Architektur |
Direkten UNC-Pfad statt DFS-Verweis verwenden (Methode 4) |
|
Sicherung hängt sich auf oder schlägt zufällig fehl |
Veraltete CIFS-Einhänge durch vorherigen fehlgeschlagenen Auftrag |
Methode 3 (Veraltete Einhänge entfernen) |
|
„Der Sicherungsmanager hat eine Ausnahme festgestellt“ (8.0) |
Zielspeicherplatz erschöpft |
Speicherplatz auf der SMB-Freigabe freigeben |
|
Sicherung schlägt fehl, NTP nicht konfiguriert |
Zeitabweichung zwischen VCSA und SMB-Server größer als 5 Minuten |
NTP auf vCenter konfigurieren (Methode 4) |
Wichtige Protokolldateien zur Fehleranalyse:
Inkompatibilitäten des SMB-Protokolls sind die häufigste Fehlerursache. Viele ältere VCSA-Versionen nutzten standardmäßig SMBv1, solange SMBv2 nicht explizit aktiviert wurde. Moderne Windows Server und NAS-Systeme deaktivieren SMBv1 jedoch aus Sicherheitsgründen. Dadurch kann der VCSA-Sicherungsvorgang keine kompatible SMB-Protokollversion aushandeln. Die Aktivierung von SMBv2 auf der VCSA löst das Problem in den meisten Fällen.
Schritt 1: Per SSH auf die VCSA verbinden und die Bash-Shell aktivieren:
shell.set --enabled true
shell
Schritt 2: Überprüfung des aktuellen Registry-Werts für SMBv2 (optional zur Kontrolle):
/opt/likewise/bin/lwregshell list_values '[HKEY_THIS_MACHINE\Services\lwio\Parameters\Drivers\rdr]'
Der Wert Smb2Enabled ist standardmäßig 0 (deaktiviert).
Schritt 3: Aktivieren von SMBv2 durch Setzen des Registry-Schlüssels
Falls der Schlüssel noch nicht existiert:
/opt/likewise/bin/lwregshell add_value '[HKEY_THIS_MACHINE\Services\lwio\Parameters\Drivers\rdr]' Smb2Enabled REG_DWORD 1
Falls der Schlüssel bereits vorhanden ist:
/opt/likewise/bin/lwregshell set_value '[HKEY_THIS_MACHINE\Services\lwio\Parameters\Drivers\rdr]' Smb2Enabled REG_DWORD 1
Schritt 4: Neustart des Likewise-E/A-Dienstes:
/opt/likewise/bin/lwsm restart lwio
Schritt 5: Überprüfung der SMB-Verbindung zum Sicherungsserver:
/usr/bin/smbclient -L //<FQDN-des-SMB-Servers>/ -U <Benutzername>
Bei erfolgreicher Verbindung nutzt die VCSA SMBv2 oder SMBv3.
Schritt 6: Führen Sie die Sicherung erneut über die VAMI-Oberfläche (https://<VCSA-IP>:5480) durch und prüfen Sie, ob sie vollständig ausgeführt wird. Sollte die vCenter-SMB-Sicherung weiterhin fehlschlagen, lesen Sie die detaillierten SMB-Handshake-Fehler in /var/log/vmware/applmgmt/backup.log nach.
Wenn Sie vCenter 7.0 U3 bis U3b mit aktiviertem FIPS-Modus betreiben oder das DFS-Namespace-Problem ab Version 7.0 U3h auftritt, löst ein Versionsupgrade das Problem dauerhaft.
Geeignete Upgrade-Pfade:
|
Aktuelle Version |
Zielversion |
Behobener Fehler |
|
7.0 U3 – 7.0 U3b |
7.0 U3c oder neuer |
SMB-Sicherungsfehler bei aktiviertem FIPS-Modus (KB 318185) |
|
7.0 U3h+ mit DFS-Namespaces |
7.0 U3o+ oder 8.0 U1+ |
Einschränkung bei Kerberos-DNS-TXT-Paketen |
|
8.0 U2 |
8.0 U2d+ oder 8.0 U3 |
Fehler bei der Auflösung kurzer Hostnamen |
Schritt-für-Schritt-Vorgehen:
Schritt 1: Laden Sie die passende ISO von Broadcom Customer Connect herunter (support.broadcom.com).
Schritt 2: Binden Sie die ISO über den vSphere-Client oder eine Out-of-Band-Verwaltung an die VCSA an.
Schritt 3: Öffnen Sie die VAMI-Oberfläche (https://<VCSA-IP>:5480), wechseln Sie in den Bereich „Update“ und laden Sie das Update hoch bzw. installieren Sie es.
Schritt 4: Nach abgeschlossenem Upgrade und dem Neustart der VCSA prüfen Sie die Build-Nummer und führen Sie die Sicherung erneut aus.
In einigen Fällen schlägt die vCenter-Sicherung fehl, weil die vorherige SMB-Einhängesitzung nicht ordnungsgemäß freigegeben wurde. Die VCSA speichert veraltete CIFS-Einhängeinformationen auch nach einem abgebrochenen Sicherungsauftrag, wodurch nachfolgende Versuche mit folgenden Fehlern enden:
– Der SMB-Speicherort ist ungültig
– Der Sicherungsmanager hat eine Ausnahme festgestellt
– Verbindung zum SMB-Speicherort fehlgeschlagen
– Der Pfad wurde vom entfernten Dateisystem nicht exportiert
Das Entfernen alter SMB-Einhänge und das erneute Einbinden der Freigabe behebt das Problem häufig.
Schritt 1: Per SSH auf die VCSA verbinden
Aktivieren Sie SSH auf der VCSA, falls es noch nicht aktiv ist.
Stellen Sie anschließend die SSH-Verbindung her:
ssh root@ihr-vcenter-server
Melden Sie sich an und öffnen Sie die Bash-Shell:
shell
Schritt 2: Ermitteln Sie zunächst den aktuell genutzten SMB-Einhängepfad, bevor Sie Einhänge entfernen.
Führen Sie folgenden Befehl aus:
mount | grep cifs
Beispielausgabe:
//backupserver.company.local/vcsa-backup auf /storage/remote/backup/cifs/52f3d2d8 Typ cifs
Das Einhängeverzeichnis enthält ggf. eine dynamisch generierte ID statt des Namens der SMB-Freigabe. Der Pfad ist nicht fest vorgegeben.
Schritt 3: Nutzen Sie den im vorherigen Schritt ausgegebenen Einhängepfad.
Beispiel:
umount /storage/remote/backup/cifs/52f3d2d8
Falls der Einhang belegt oder blockiert ist, erzwingen Sie das Aushängen:
umount -f /storage/remote/backup/cifs/52f3d2d8
Überprüfen Sie, ob der Einhang erfolgreich entfernt wurde:
mount | grep cifs
Keine Ausgabe bedeutet, dass der SMB-Einhang gelöscht wurde.
Schritt 4: Starten Sie den Geräteverwaltungsdienst neu, um alle Sicherungssitzungen zurückzusetzen:
service-control --restart applmgmt
Warten Sie einige Minuten, bis der Dienst vollständig neu gestartet ist.
Wechseln Sie anschließend zurück zur VAMI-Oberfläche und konfigurieren Sie den SMB-Sicherungsauftrag neu.
Falls die oben genannten Verfahren den Fehler „vCenter-Sicherung: SMB nicht unterstützt“ nicht beheben, prüfen Sie folgende Konfigurationseinstellungen:
● Nutzen Sie den FQDN, keinen kurzen Hostnamen:
Geben Sie im VAMI-Feld für den Sicherungsziel immer den vollständigen Domänennamen ein (z. B. //backupserver.ihrdomain.local/freigabe), niemals nur den kurzen Hostnamen (z. B. //backupserver/freigabe). Dies ist ab vCenter 8.0 U2 zwingend erforderlich, stellt aber für alle Versionen eine bewährte Vorgehensweise dar.
● Vollständige Administratorrechte für das Sicherungsdienstkonto gewähren:
Das zur Authentifizierung an der SMB-Freigabe genutzte Konto muss Schreib- und Löschrechte besitzen. Broadcom empfiehlt die Nutzung eines Administratorkontos oder eines Benutzers mit vollen Administratorrechten auf dem Sicherungsverzeichnis.
● NTP-Synchronisation einrichten:
Prüfen Sie die Zeitsynchronisation zwischen VCSA und SMB-Server:
ntpq -p
Falls NTP auf der VCSA nicht konfiguriert ist, richten Sie es über die VAMI-Oberfläche ein: Netzwerk > Zeit > Bearbeiten. Die Zeitabweichung zwischen VCSA und SMB-Server muss unter 5 Minuten liegen, damit die Kerberos-Authentifizierung funktioniert.
● Vermeiden Sie DFS-Namespaces (ab 7.0 U3h):
Wenn Sie vCenter 7.0 U3h oder neuer nutzen und einen DFS-Namespace als Sicherungsziel verwenden, wechseln Sie zum direkten UNC-Pfad des eigentlichen Dateiservers (z. B. //server01.domain.local/freigabe statt //domain.local/namespace/freigabe).
Einige Administratoren aktivieren SMBv1 als schnelle Notlösung – dies sollte aber nur auf Test-Sicherungsservern, nicht in der Produktivumgebung erfolgen.
SMBv1 verfügt über keine Verschlüsselung, gegenseitige Authentifizierung, Integritätsprüfungen und keinen Schutz vor Man-in-the-Middle-Angriffen. Der Exploit EternalBlue (CVE-2017-0144) zielt gezielt auf SMBv1 ab und war der Hauptangriffsvektor der WannaCry-Ransomware-Epidemie, die weltweit hunderttausende Systeme betraf.
Microsoft hat SMBv1 vor über einem Jahrzehnt als veraltet eingestuft. Alle gängigen Sicherheits-Compliance-Rahmenwerke (CIS, NIST, Cyber Essentials) schreiben die Deaktivierung vor. Selbst in isolierten Laborumgebungen stellt die Aktivierung von SMBv1 ein hohes Sicherheitsrisiko dar. Die korrekte Lösung ist die Konfiguration der VCSA zur Nutzung von SMBv2/SMBv3 oder der Wechsel zu einem sichereren Protokoll.
Falls die vCenter-SMB-Sicherung nach allen genannten Verfahren weiterhin fehlschlägt, wechseln Sie zu einem der offiziell unterstützten Protokolle. Jedes hat spezifische Vorteile:
|
Protokoll |
Sicherheit |
Leistung |
Einsatzzweck |
|
FTPS (Explizit) |
TLS-Verschlüsselung, zertifikatsbasierte Authentifizierung |
Schnell |
Umgebungen mit vorhandener FTP-Infrastruktur, funktioniert über Proxys |
|
NFS |
Kerberos (v4) oder IP-basierte Zugriffskontrolllisten |
Hoch, natives Linux-Protokoll |
Homogene VMware/Linux-Umgebungen, vermeidet alle SMB-Kompatibilitätsprobleme |
|
SFTP |
SSH-Verschlüsselung, schlüsselbasierte Authentifizierung |
Mittel (SSH-Overhead) |
Standortübergreifende Sicherungen, firewallfreundlich (Port 22) |
|
HTTPS (WebDAV) |
TLS-Verschlüsselung, zertifikatsbasierte Authentifizierung |
Mittel |
Umgebungen mit vorhandener Webserver-Infrastruktur |
vCenter unterstützt offiziell sieben Sicherungsprotokolle: FTP, FTPS, HTTP, HTTPS, SFTP, NFS und SMB.
NFS ist oft die zuverlässigste Alternative für VMware-Umgebungen, da es nativ unter Linux läuft (das Betriebssystem der VCSA) und keinen SMB-Protokollstack benötigt. Wenn Sie einen NFS-Server oder ein NAS-Gerät mit exportierten NFS-Freigaben betreiben, beseitigt die Nutzung als vCenter-Sicherungsziel alle SMB-Protokollprobleme vollständig.
FTPS (FTP über explizites TLS) ist eine weitere gute Wahl für Windows-zentrierte Umgebungen. Es bietet verschlüsselten Datentransport ohne die Kompatibilitätsprobleme von SMB-Versionen.
Die integrierte dateibasierte Sicherung der VAMI-Oberfläche eignet sich zwar zum Schutz der vCenter-Konfiguration, weist jedoch gravierende Einschränkungen auf: Sie sichert keine virtuellen Maschinen, verfügt nicht über Unternehmensfunktionen wie Deduplizierung und zentrales Management und birgt Protokollprobleme wie den in diesem Artikel beschriebenen SMB-Fehler.
Für Unternehmen mit mehreren vCenter-Instanzen oder einer umfassenden Datenschutzstrategie bietet i2Backup von Info2soft (i2Backup) eine stabilere Lösung:
Fordern Sie jetzt über den Download-Button eine kostenlose 60-Tage-Testversion an.
Der Fehler „vCenter-Sicherung: SMB nicht unterstützt“ entsteht durch einen grundlegenden Protokollkonflikt: Der veraltete SMB-Client der VCSA nutzt standardmäßig SMBv1, während moderne Dateiserver SMBv1 aus Sicherheitsgründen deaktivieren. Hinzu kommen Fehler im FIPS-Modus, Inkompatibilitäten mit DFS-Namespaces, veraltete Einhängepunkte und fehlerhafte DNS-Konfigurationen.
Der schnellste Lösungsweg:
Ein defektes vCenter-Sicherungssystem darf nicht aufgeschoben werden – Ihre vCenter-Konfiguration (Inventar, Rollen, Berechtigungen, Verteilte Switch-Einstellungen) ist kritische Infrastruktur. Ohne funktionsfähige Sicherung kann ein vCenter-Ausfall mehrtägige manuelle Wiederherstellungsarbeiten nach sich ziehen. Zur einfachen Sicherung aller VMware-Gast-VMs empfehlen sich zudem die Lösungen von Info2soft.
· Unternehmenskunden und Mittelstand weltweit
· Unser Support-Team unterstützt Sie während der gesamten Testphase
· Starten Sie eine 60-tägige Testversion oder sehen Sie sich eine Demo an, um zu erfahren, wie Info2Soft Unternehmensdaten schützt.