Zum Inhalt

Container-Update: Nativ zu VM (Virtual Machine)

Diese Anleitung beschreibt den Prozess der Migration einer bestehenden nativen charly-Server Installation auf eine neue charly-VM (Container-basierte Installation). Ziel ist es, die Ausfallzeit für die Praxis zu minimieren, indem Vorbereitungen während der Betriebszeiten getroffen werden.

Strategie: Effiziente Migration mit minimaler Ausfallzeit

Diese Anleitung fokussiert sich auf den empfohlenen Migrationspfad, der darauf abzielt:

  1. Ausfallzeit zu minimieren: Der Großteil der Vorbereitung (Datenübertragung, VM-Installation) kann während der Praxiszeiten erfolgen.
  2. Gesamtdauer zu verkürzen: Statt eine riesige ISO-Datei (Image-Datei) mit allen Daten zu erstellen, werden Datenbank und Dateien (Ablage etc.) getrennt und effizient über einen SMB (Server Message Block) Share übertragen. Das zeitaufwändige Kopieren der charly.7z-Datei findet im Hintergrund statt (transfer-files).
  3. Arbeitszeit effizient zu nutzen: Viele Schritte auf dem Quell- und Zielsystem können parallel ausgeführt werden, was Wartezeiten reduziert. Das Kopieren der Ablage erfolgt ferner ohne menschliche Supervision.
  4. Gezielte & schnelle Umstellung zu ermöglichen:
    • Ein Vorabtest der VM-Installation und der grundlegenden Funktionalität ist mit einem schnellen Datenbank-Snapshot (export databaseiso) möglich.
    • Die finale Umstellung (export migration) beschränkt sich auf den Export des letzten Datenbankstands und kleinerer Dateiänderungen auf den Share. Dies ist deutlich schneller als das Erstellen einer kompletten Migrations-ISO.
    • Der anschließende Datenimport auf der Ziel-VM (vm restore/restore-files) ist ebenfalls optimiert.
    • Ziel: Die kritische Umstellungsphase außerhalb der Praxiszeiten kann so, bei guter Vorbereitung und adäquater Hardware, oft in unter einer Stunde abgeschlossen werden.

Kernschritte der empfohlenen Strategie:

  1. Vorbereitung (Während der Praxiszeiten):
    • SMB Share einrichten.
    • export databaseiso -> SMB Share (notwendig für VM-Installation).
    • export transfer-files -> SMB Share (überträgt Hauptdaten charly.7z).
    • Parallel: charly-server install auf Zielsystem (mit databaseiso).
    • charly-server vm backup-config auf Zielsystem (nutzt SMB Share).
  2. Finale Umstellung (Außerhalb der Praxiszeiten):
    • charly-server export migration -> SMB Share (stoppt Quelle, exportiert finalen DB-Stand postgres.tar.gz, aktualisiert charly.7z). Erzeugt keine ISO mehr!
    • charly-server vm restore / restore-files auf Zielsystem (importiert Daten vom Share).
    • Finale Tests & Go-Live.

      Bei einer VM Installation auf dem selben Server, muss der Aufruf charly-server export migration -SolutioPath <altes Solutio Verzeichnis> mit dem SolutioPath Parameter erfolgen, wenn die Auto Detection fehl schlägt.

Alternativer Ablauf (NICHT empfohlen - höhere Ausfallzeit):

  • Notwendig, wenn keine Vorbereitung (kein früherer SMB-Zugriff, keine Zeit) oder keine parallele VM-Installation (RAM-Mangel auf Host) möglich ist.
  • charly-server export migration wird mit -ISOFilePath ausgeführt, um eine komplette Migrations-ISO auf einem lokalen Laufwerk zu erstellen.
  • Diese große ISO muss anschließend manuell auf das Zielsystem übertragen werden (z.B. über Netzwerk-Kopie oder externe Medien).
  • charly-server install kann erst danach mit dieser lokalen ISO-Datei erfolgen.
  • Dies verlängert die benötigte Ausfallzeit erheblich, da zusätzlich Zeit für die ISO-Übertragung benötigt wird.

Voraussetzungen

  • Administrator-Zugriff auf den Quellserver (nativ) und den Zielserver (neue VM-Umgebung).
  • PowerShell 5 ab Version 5.1 mit Administratorrechten auf beiden Systemen.
  • Ein SMB-Netzlaufwerk (Share), das von beiden Servern aus erreichbar ist und über ausreichend Speicherplatz für den Export und das Backup verfügt.
  • Netzwerkkenntnisse zur Einrichtung des SMB-Shares und ggf. zur Konfiguration fester IP-Adressen.
  • Ressourcen auf dem Quell-System (Host):
    • Für den empfohlenen Ablauf mit VM-Installation vor der finalen Umstellung muss der Host des Quellsystems (falls die VM auf demselben Host laufen soll) über ausreichend freien Arbeitsspeicher verfügen (Richtwert: mindestens 32 GB zusätzlich zur laufenden nativen Installation), um die charly-VM parallel starten zu können.
    • Dies gilt, wenn:
      • Das Zielsystem = Quellsystem ist (Migration auf demselben Server).
      • Das Quellsystem selbst eine VM ist und die neue charly-VM auf demselben Hyper-V-Host erstellt wird.
    • Ist das Zielsystem eine dedizierte neue Hardware, entfällt diese spezifische RAM-Einschränkung für den Parallelbetrieb.

charly-Server-Skript

Stellen Sie sicher, dass das charly-server Skript auf beiden Systemen installiert und aktuell ist.

Prüfen der Installation:

charly-server

Wenn das Skript installiert ist, wird die Versionsnummer angezeigt. Ansonsten installieren Sie es:

Installation:

# Download des Installers
Invoke-WebRequest -Uri "https://charly-cdn-solutio.s3.amazonaws.com/release/windows/charly-server-install.ps1" -OutFile ".\charly-server-install.ps1"

# TLS 1.2 setzen (falls Download fehlschlägt)
# [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

# Ausführungsrichtlinie anpassen (falls nötig)
Set-ExecutionPolicy RemoteSigned -Force
# Bei Signaturproblemen:
# Set-ExecutionPolicy Unrestricted -Force

# Skript ausführen
.\charly-server-install.ps1

# Nach Abschluss ggf. zurücksetzen:
# Set-ExecutionPolicy RemoteSigned -Force

Wiederholen Sie die Installation auf dem Zielserver.

Migrations-Workflow mit parallelen PowerShell-Operationen

Die folgende Darstellung zeigt den Migrations-Workflow aufgeteilt in drei PowerShell-Fenster (QP1, QP2, ZP1) und illustriert, welche Schritte parallel ausgeführt werden können:

Schritt-für-Schritt Anleitung (Empfohlener Pfad)

Legende:

  • Q: Quellsystem (Nativer Charly-Server)
  • Z: Zielsystem (Hyper-V Host für die charly-VM)
  • QP1, QP2: PowerShell-Fenster 1 und 2 auf dem Quellsystem.
  • ZP1: PowerShell-Fenster 1 auf dem Zielsystem.
  • SMB Share: Zentrales Netzlaufwerk (UNC-Pfad: \\SERVERNAME\SHARENAME)

Setup:

  1. Alle Systeme: Öffnen Sie die benötigten PowerShell-Fenster (QP1, QP2, ZP1) mit Administratorrechten.
  2. Alle Systeme: Stellen Sie sicher, dass das charly-server-Skript installiert und aktuell ist (siehe Voraussetzungen).
  3. Planung:
    • Notieren Sie UNC-Pfad und Anmeldedaten für den SMB Share.
    • Legen Sie die finale statische IP-Adresse für die neue charly-VM fest und prüfen Sie deren Verfügbarkeit (ping).
  4. Zielsystem/Netzwerk: Richten Sie den SMB Share ein, stellen Sie Erreichbarkeit und ausreichenden Speicherplatz sicher.

Phase 1: Vorbereitung (Während der Praxiszeiten)

  • Ziel: Systeme prüfen, eine Test-DB-ISO erstellen, Hauptdaten (charly.7z) auf den Share übertragen, Ziel-VM installieren und Backup konfigurieren.

  • [ZP1] Zielsystem: Systemcheck.

    # Prüft Hyper-V, Ressourcen etc.
    charly-server check-system
    

  • [QP1] Quellsystem: Systemcheck.
    # Prüft Konfiguration, Speicherplatz etc.
    charly-server check-system
    
  • [QP2] Quellsystem: Datenbank-Test-ISO exportieren:

    • Zweck: Ermöglicht eine frühe Installation und Test der VM auf dem Zielsystem.
    • Ausführung: Kann während des Praxisbetriebs erfolgen.

      # Exportiert DB-Snapshot als ISO auf lokales Laufwerk (ISO-Dateien werden automatisch lokal erstellt)
      charly-server export databaseiso -ExportPath "\\SERVERNAME\SHARENAME"
      

      ISO-Dateien werden nur lokal erstellt

      ISO-Dateien werden aus Performance-Gründen immer auf einem lokalen Laufwerk erstellt, auch wenn der ExportPath ein Netzwerk-Share ist. Das System wählt automatisch ein geeignetes lokales Laufwerk für die ISO-Erstellung aus. Die ISO-Datei muss anschließend manuell auf den Share oder das Zielsystem kopiert werden. * Nach Abschluss des Exports werden Netzwerkfreigabe-Informationen angezeigt, einschließlich des UNC-Pfads und des mount-backup-drive Befehls für das Zielsystem.

      1. [QP2] Quellsystem: Charly-Dateien übertragen:
        • Zweck: Überträgt den Großteil der Daten (Ablage etc.) als komprimiertes charly.7z-Archiv auf den SMB Share. Minimiert die Datenmenge für export migration.
        • Ausführung: Kann während des Praxisbetriebs erfolgen. Aktualisiert eine eventuell vorhandene charly.7z-Datei.

      Dieser Befehl erstellt bzw. aktualisiert charly.7z auf dem Share

      charly-server export transfer-files -ExportPath "\\SERVERNAME\SHARENAME"
      
      5. (Parallel zu 3 & 4) [ZP1] Zielsystem: SMB-Share mounten und VM-Installation starten: * Voraussetzung: Genügend RAM auf dem Host des Zielsystems (siehe Voraussetzungen), falls Ziel = Quelle oder beide VMs auf demselben Host liegen. * SMB-Share mounten:

      Mountet den SMB-Share vom Quellsystem (der exakte Befehl wird nach export databaseiso angezeigt. Diesen bitte kopieren anstelle des Beispiels hier)

      charly-server export mount-backup-drive -UNCPath "\\SERVERNAME\SHARENAME"
      
      * Wichtig: Sie müssen den SMB-Share in einer Administrator-PowerShell mounten, da die VM-Installation ebenfalls mit Administrator-Rechten ausgeführt wird. Ein Mount als normaler Benutzer ist für die Installation nicht ausreichend, da die Laufwerkszuordnungen pro Benutzer gelten und in der Administrator-Umgebung nicht sichtbar wären. * Installation mit DB-Test-ISO:

      Da die ISO-Datei lokal auf dem Quellsystem erstellt wurde, muss sie zuerst auf das Zielsystem kopiert werden. Nach dem Kopieren verwenden Sie den lokalen Pfad zur ISO-Datei:

      # Beispiel: ISO-Datei wurde nach C:\Temp\database.iso kopiert
      charly-server install -PathFilesISO "C:\Temp\database.iso"
      
      * Folgen Sie den Anweisungen. Geben Sie die finale, geplante IP-Adresse an. Notieren Sie sich das Admin-Passwort.

  • [ZP1] Zielsystem: Frühe Verifizierung durchführen:

    • Browsertest: Prüfen Sie, ob http://<VM-IP> erreichbar ist und die Charly-Startseite angezeigt wird.
    • PGAdmin: Verbinden Sie sich mit PGAdmin (Host: <VM-IP>, User: postgres) und prüfen Sie, ob in solutiodb.version die Lizenzdaten (anzahl, praxis) korrekt angezeigt werden.
    • Client-Test: Laden Sie den Client herunter und prüfen Sie die Anmeldung.
  • [ZP1] Zielsystem: Backup konfigurieren:

    • Zweck: Absolut notwendig für die Datensicherheit der neuen VM.
    • Konfiguration: Nutzen Sie den SMB Share als Ziel.
      charly-server vm backup-config
      
      Folgen Sie den Anweisungen (UNC-Pfad, Credentials, Zeitplan).

Phase 2: Finale Umstellung (Außerhalb der Praxiszeiten!)

  • Ziel: Quellsystem stoppen, finalen DB-Stand exportieren, Daten auf Ziel-VM wiederherstellen.

  • [QP1] Quellsystem: Finalen Migrations-Export starten:

    • Zweck: Stoppt die native Installation, exportiert den letzten Stand der Datenbanken (postgres.tar.gz) und aktualisiert charly.7z auf dem SMB Share.
    • WICHTIG: Benötigt Ausfallzeit für die Praxis! Exportiert finalen DB-Stand & aktualisiert charly.7z auf dem Share und erzeugt KEINE ISO mehr!

      charly-server export migration
      

      SolutioPath Parameter bei VM auf gleichem Server

      Wenn die VM auf dem selben Server läuft wie die alte Installation, muss zwingend der SolutioPath Parameter angegeben werden, da das Script nicht mehr in der Lage ist herauszufinden, wo der alte Server läuft:

      charly-server export migration -SolutioPath "C:\Solutio"
      
      * Nach Abschluss des Exports werden Netzwerkfreigabe-Informationen angezeigt, einschließlich des UNC-Pfads und der auf dem Zielsystem zu verwendenden Anmeldeinformationen. * !!! warning "Migrationsmodus"

      • Stoppt Charly-Dienste und deaktiviert sie dauerhaft.
      • Kann je nach DB-Größe dauern.
      • [ZP1] Zielsystem: Daten wiederherstellen (Nach Abschluss von export migration):

    Stellt finalen DB-Stand UND Dateien komplett wieder her

    charly-server vm restore
    

Phase 3: Verifizierung & Abschluss

  • Ziel: Sicherstellen, dass die neue VM korrekt funktioniert.

  • [ZP1] Zielsystem: Status prüfen:

    charly-server vm status
    
    Stellen Sie sicher, dass die VM läuft und alle Container grün sind.

  • Verifizierung Teil 1 (Direkt nach restore):
    • Browser: Prüfen Sie Dozzle (http://<VM-IP>:9001) und Eureka (http://<VM-IP>:8761).
    • PGAdmin: Verbinden Sie sich erneut. Prüfen Sie solutiodb.version (sollte jetzt definitiv die korrekten Lizenzinfos enthalten) und ggf. andere Tabellen stichprobenartig.
  • Verifizierung Teil 2 (Client-Tests):
    • Test-Arbeitsplatz: Installieren/Starten Sie den charly-client (Download von http://<VM-IP>).
    • Anmeldung & Basistests: Prüfen Sie Login, DB-Version, Konnektor, KIM.
    • Ablage: Überprüfen Sie unbedingt bei mehreren Patienten, ob Dokumente in der Ablage korrekt angezeigt werden.
  • Verifizierung Teil 3 (Netzwerk-Tests):
    charly-server vm test-network
    
    Stellen Sie sicher dass der Konnektor, KIM und die TI-Routen korrekt funktionieren.
  • (Optional) [ZP1] Zielsystem: IP-Adresse ändern: Nur falls unbedingt nötig.
    charly-server vm ip-config
    
    !!! warning "IP-Änderung" Erfordert Neuinstallation aller charly-clients!
  • Finale Tests: Führen Sie umfassende Tests auf mehreren Arbeitsplätzen durch.
  • Quellserver: Alte Installation entfernen: Erst wenn die neue VM mehrere Tage stabil und fehlerfrei läuft. Sichern Sie vorher alle Daten!

Rollback bei Fehlern:

Nur bevor produktiv mit der neuen VM gearbeitet wurde!

  1. [QP1] Quellsystem: Dienste wieder starten !!! warning "Vorherige DB Migration mit mehreren PostgreSQL Verzeichnissen (zum Beispiel ein PostgreSQL13 + PostgreSQL Ordner)" In diesem Fall muss man ggf. den C:\Solutio\Server\PostgreSQL ordner umbennen in C:\Solutio\Server\PostgreSQL.VERYOLD damit das Skript den richtigen Ordner findet.
    charly-server manage start
    
  2. [ZP1] Zielsystem: Fehlgeschlagene Installation bereinigen
    charly-server vm uninstall
    

Datenverlust bei Rollback nach Nutzung

Kontaktieren Sie bei Problemen nach produktiver Nutzung der VM umgehend den Support!

Konfiguration bei mehreren Mandanten

Wenn die klassische Installation mehrere Mandanten verwendet hat, muss die Konfiguration entsprechend angepasst werden:

  1. Mandanten prüfen
  2. Konfiguration in application.yml eintragen
  3. Container neu starten
  4. Konfiguration testen

Wenn nur ein Mandant verwendet wird, also der Standardfall, muss keine Anpassung vorgenommen werden.

1. Mandanten prüfen

Es muss geprüft werden, ob es mehrere Mandanten gibt. In diesem Fall entält die Datei Solutio.app/Mandanten.flg einen oder mehrere Einträge wie (Beispiel):

1 767226552 Mandant 2

Außerdem muss es neben der Ablage auch Mandant2, möglicherweise Mandant3 und weitere geben.

2. Konfiguration eintragen

Status aufrufen, um den SMB Share zu finden:

charly-server vm status

Den SMB Share charly-config mit dem User smbadminuser und dem Administrator Passwort mounten (Siehe: Verbinden des Samba-Share "charly-config"). Darin findet sich die Datei conf2/_global/application.yml. In diese Datei folgendes eintragen.

Bei einem 2. Mandanten:

de.solutio.tenant.ids: 1,2

de.solutio.tenant.names.1: tenant-1
de.solutio.tenant.names.2: tenant-2

de.solutio.charly.datasource.tenant2.host: database
de.solutio.charly.datasource.tenant2.username: postgres
de.solutio.charly.datasource.tenant2.password: ${POSTGRES_PASSWORD}
de.solutio.charly.datasource.tenant2.driver-class-name: org.postgresql.Driver
de.solutio.charly.datasource.tenant2.jdbc-url: jdbc:postgresql://${de.solutio.charly.datasource.tenant2.host}:${de.solutio.charly.datasource.tenant2.port}/${de.solutio.charly.datasource.tenant2.name}?ApplicationName=${spring.application.name}
de.solutio.charly.datasource.tenant2.name: solutiodb2
de.solutio.charly.datasource.tenant2.platform: postgresql
de.solutio.charly.datasource.tenant2.port: 5432
de.solutio.charly.filing.tenant2: /charly/mutable/Mandant2/Ablage

Bei einem 2. und 3. Mandanten:

de.solutio.tenant.ids: 1,2,3

de.solutio.tenant.names.1: tenant-1
de.solutio.tenant.names.2: tenant-2
de.solutio.tenant.names.3: tenant-3

de.solutio.charly.datasource.tenant2.host: database
de.solutio.charly.datasource.tenant2.username: postgres
de.solutio.charly.datasource.tenant2.password: ${POSTGRES_PASSWORD}
de.solutio.charly.datasource.tenant2.driver-class-name: org.postgresql.Driver
de.solutio.charly.datasource.tenant2.jdbc-url: jdbc:postgresql://${de.solutio.charly.datasource.tenant2.host}:${de.solutio.charly.datasource.tenant2.port}/${de.solutio.charly.datasource.tenant2.name}?ApplicationName=${spring.application.name}
de.solutio.charly.datasource.tenant2.name: solutiodb2
de.solutio.charly.datasource.tenant2.platform: postgresql
de.solutio.charly.datasource.tenant2.port: 5432
de.solutio.charly.filing.tenant2: /charly/mutable/Mandant2/Ablage

de.solutio.charly.datasource.tenant3.host: database
de.solutio.charly.datasource.tenant3.username: postgres
de.solutio.charly.datasource.tenant3.password: ${POSTGRES_PASSWORD}
de.solutio.charly.datasource.tenant3.driver-class-name: org.postgresql.Driver
de.solutio.charly.datasource.tenant3.jdbc-url: jdbc:postgresql://${de.solutio.charly.datasource.tenant3.host}:${de.solutio.charly.datasource.tenant3.port}/${de.solutio.charly.datasource.tenant3.name}?ApplicationName=${spring.application.name}
de.solutio.charly.datasource.tenant3.name: solutiodb3
de.solutio.charly.datasource.tenant3.platform: postgresql
de.solutio.charly.datasource.tenant3.port: 5432
de.solutio.charly.filing.tenant3: /charly/mutable/Mandant3/Ablage

3. Container neu starten

Die Container müssen neu gestartet werden, um die Konfiguration zu aktivieren:

charly-server vm docker-rebuild

4. Konfiguration testen

Starten Sie den charly-Client, melden Sie sich unter den Mandanten mit einem Benutzer an und prüfen Sie, ob der Web-Client geladen werden kann.

Wichtige Hinweise

  • Die Vorbereitung während der Praxiszeiten (export databaseiso, transfer-files) ist der Schlüssel zur Minimierung der Ausfallzeit.
  • export migration ist der kritische Schritt, der die Ausfallzeit bestimmt und das Quellsystem deaktiviert.
  • Der SMB Share ist zentral für den Datenaustausch und das Backup.
  • Die Backup-Konfiguration (vm backup-config) ist essentiell.
  • vm restore / restore-files sind notwendig, um die finalen Daten vom Share in die VM zu bringen.
  • Beachten Sie die RAM-Voraussetzungen für den Parallelbetrieb von Quellsystem und Test-VM auf demselben Host.
  • Die frühe Verifizierung nach der Installation mit database.iso ermöglicht es, Probleme zu identifizieren, bevor große Datenmengen (100GB+) übertragen werden.

Troubleshooting

1. charly Client startet nicht oder es werden nur leere Fenster angezeigt

Prüfen Sie, ob die NeXT Prozesse (pbs.exe und WindowServer.exe) mehrfach gestartet sind. Falls ja, beenden Sie diese. Starten Sie die Prozesse dann neu, indem Sie im Ausführen-Dialog (Win + R oder Rechtsklick auf Start -> Ausführen) shell:common startup eingeben. Im sich öffnenden Ordner starten Sie pbs.exe und WindowServer.exe.

Falls die Dateien nicht vorhanden sind, ist NeXT nicht installiert. Installieren Sie dieses.

Falls das Problem weiterhin besteht, kann es sein, dass die NeXT Installation beschädigt ist. Installieren Sie NeXT neu.

2. Fehlermeldung beim Versuch, eine SSH Verbindung herzustellen: WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! (man-in-the-middle attack)

Der SSH Schlüssel der VM wurde geändert und passt nicht mehr zum public key in der VM.

Lösung: In der Datei %USERPROFILE%\.ssh\known_hosts den Eintrag für die VM entfernen. In der Fehlermeldung steht die Zeile, in der der problematische Schlüssel steht.

3. KIM (Kommunikation im Medizinwesen) funktioniert nicht

Prüfen Sie in charly-web, ob in der Konnektor Übersicht die HBA Karte sichtbar ist. Die Karte muss stecken und der Computer, an dem die Karte im Terminal steckt, muss angeschaltet sein.

4. Anamnese Daten erscheinen nicht in charly

Prüfen Sie, ob die IP in der Anamnese App korrekt ist. Insbesondere nach einem Container-Update muss die IP in der Anamnese App korrekt eingegeben werden.

5. Logdateien der Sterilisatoren erscheinen nicht in charly

Prüfen Sie, ob die Ablage korrekt im Programm des Sterilisators eingetragen ist. Insbesondere nach einem Container-Update muss die Ablage korrekt eingebunden werden. Prüfen Sie hierfür auch das Netzlaufwerk der Ablage.

6. Das Backup kann nicht konfiguriert bzw. erstellt werden

Hierfür gibt es mehrere mögliche Ursachen:

  1. charly-server ist nicht aktuell. Führen Sie Folgendes aus:
charly-server vm update-setup

Prüfen Sie die Berechtigungen des Benutzers, der für das Backup verwendet werden soll. Vergeben Sie nicht nur Vollzugriff, sondern auch Lesen, Schreiben und Ändern.

7. Es kann kein Backup konfiguriert werden

Hierfür gibt es mehrere mögliche Ursachen

  1. charly-server ist nicht aktuell. Führen Sie Folgendes aus:
charly-server vm update-setup
  1. Der Benutzer, der das Backup verwendet, hat nicht die richtigen Berechtigungen. Stellen Sie sicher, dass der Benutzer Vollzugriff auf den Ordner hat. Prüfen Sie dies in den Ordnereigenschaften sowohl im Tab "Freigabe" als auch im Tab "Sicherheit". Fügen Sie den Benutzer ggs. mit Vollzugriff-Rechten hinzu (inklusive Lesen, Schreiben und Ändern).
  2. Das Netzlaufwerk kann nicht verbunden werden. Testen Sie die Verbinung manuell mit dem vorgesehenen Benutzer. Falls dies nicht funktioniert, prüfen Sie, ob eine Firewall blockiert.
  3. Es kann verbunden werden, jedoch erscheint die Meldung, dass keine Schreibrechte vorhanden sind. Prüfen Sie die Berechtigungen des Benutzers.
  4. Es erscheint die Meldung Unable to connect to SMB share und beim Aufruf von charly-server vm test-config kommt die Meldung mount error(95): Operation not supported. Refer to mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg). Das externe Laufwerk unterstützt SMB 3 nicht.

Diese Anleitung bietet einen Überblick über den Migrationsprozess. Für detailliertere Informationen oder bei spezifischen Problemen wenden Sie sich bitte an den Support.


Version: 2.7.1

Datum der letzten Aktualisierung: 25.09.2025