Basic Backup – 3rdParty App für Synology NAS (DSM 7)

[Lord Helmchen]

Super! Vielen Dank! Ich hoffe, dass der Osterhase Dich auf gute Ideen bringt. Falls Du einen Testuser suchst, der IT-affin ist und früher sein eigens handgefrickeltes Backup-Script auf der Syno laufen hatte, melde ich mich freiwillig.

 

[Tommes]

Hi!

Ich hab mich heut morgen ein wenig eingelesen und kurz etwas rumprobiert. Dabei ist mir gleich der erste Dämpfer über den Weg gelaufen. Um verschlüsselte Ordner einzuhängen und/oder zu trennen, benötigt man in jedem Fall root-Rechte. Solang wir nur von lokalen Quell- und/oder Zielordner reden, sollte das einhängen und/oder trennen durchaus machbar sein. Jedoch hätte man über die GUI keine Möglichkeit, diese anzusteuern. Einzig das eigentliche rsync-Script, welches den Auftrag ausführt, verfügt über root-Rechte und nur hier kann mit verschlüsselten Ordnern interagiert werden. Aber machbar wäre es.

Nicht machbar ist hingegen die Interaktion mit verschlüsselten Ordnern auf einer Remote DiskStation oder auf kompatiblen rsync-Remote-Servern, da auch in diesem Fall root-Rechte benötigt werden. Das gibt i.d.R. jedoch die SSH-Verbindung, zumindest unter Verwendung einer Remote DiskStation nicht her, da man sich "im Normalfall" nicht per SSH als root auf eine Remote DiskStation aufschalten kann. Mit kompatiblen rsync-Remote-Servern könnte das dann schon eher funktionieren, müsste für den Einzelfall aber stets getestet werden.

Unter Verwendung eines Remote-Servers würden sich folgende Einschränkungen ergeben.

• Bei einem Push-Backup können Quelldaten nur unverschlüsselt im Remote-Ziel abgelegt werden, außer es handelt sich bei dem Quellordner um einen bereits verschlüsselten und getrennten Ordner. Dieser würde dann einfach ins Remote-Ziel, ebenfalls verschlüsselt übertragen bzw. kopiert werden.
  
  
• Bei einem Pull-Backup können die Quelldaten eines Remote-Servers, im lokalen Ziel der DiskStation verschlüsselt oder unverschlüsselt abgelegt werden. Verschlüsselte und getrennte Ordner, die sich auf dem Remote-Server befinden, könnten jedoch nur verschlüsselt ins lokale Ziel übertragen bzw. kopiert werden.

Ich muss mich jetzt ein wenig sortieren und überlegen, wie sich das alles am besten umsetzten lässt. Grade beim Umgang mit verschlüsselten Remote Ordnern, die einfach nur von der Quelle ins Ziel "kopiert" werden, habe ich ein wenig Bauchschmerzen. Um solch einen Ordner einhängen zu können, muss man sich definitiv mit der Konsole auseinandersetzten. Bei lokalen Geschichten könnte man das einhängen und/oder trennen ggfl. noch über die DSM-Ordnerverschlüsselung managen, außer man wählt individuelle Zielordner, auf die der DSM keinen Zugriff hat. Schwierig, schwierig...

Tommes

 

[Lord Helmchen]

Vielen Dank dafür, Dir das anzusehen. Für mich ist aktuell nur das lokale Backup auf eine lokale USB- bzw. ESATA-Festplatte interessant.

Remote Replikation von wichtigen Daten mache ich nicht auf eine andere NAS, sondern in One.Drive über einen WebDAV-Proxy.

 

[Tommes]

Hi!
Ich hab mir in den letzten Tagen ein kleines Script geschrieben, mit dem ich einen frei wählbaren Ordner verschlüsselten, einhängen und trennen kann. Das Ganze beruht dabei auf dem Verschlüsselungssystem eCryptfs, welches auch Synology für die Ordnerverschlüsselung nutzt. Dazu später mehr.

Um einen verschlüsselten Ordner später automatisiert, oder aber auf einem anderen System wieder einhängen zu können, benötigt man eine Schlüsseldatei (Synology spricht hier von einem Verschlüsselungsschlüssel), die das Passwort zum Entschlüsseln enthält. Diese Schlüsseldatei wird wiederum durch eine Passphrase durch unerlaubten Zugriff geschützt. Ebenfalls wird diese Passphrase im Kernel Keyring des Systems abgelegt. Ohne diese Schlüsseldatei lässt sich ein verschlüsselter Ordner somit nur auf dem System wieder entschlüsseln, auf dem sie erstellt wurde. So habe ich es jedenfalls verstanden. So weit, so gut!

Mein Problem ist jetzt, das mir Synology es nicht erlaubt, die Schlüsseldatei über die GUI zu erstellen, weil ich hierfür root-Rechte benötige, die ich aber nicht habe. Das Einhängen und Trennen eines verschlüsselten Ordners erfolgt im späteren Verlauf über das eigentliche rsync-Script, welches dabei durchaus über root-Rechte verfügt. Jedoch benötigt das Script dafür eine entsprechende Schlüsseldatei, ohne die, wie oben bereits erwähnt, kein automatisierter Prozess zum Entschlüsseln angestoßen werden kann.

Für den Moment sieht es also eher schlecht aus, mit deinem Wunsch nach einer Zielordnerverschlüsselung. Aktuell könnte man das nur durch manuelles Einrichten, bestenfalls über die Konsole, erreichen. Das möchte ich aber niemandem zumuten und stellt für mich auch keine Lösung im Zusammenhang mit Basic Backup da.

Nichtsdestotrotz mache ich mir weitere Gedanken, wie ich das Problem lösen bzw. umgehen könnte.

Noch ein Wort zu eCryptfs, welches aktuell auch noch von Synology verwendet wird. Es ist z.B. hier zu lesen, das das Projekt seit 2019 bzw. 2020 nicht mehr weitergeführt wird und das auch ein, seit langen bekannter Bug nicht beseitigt werden konnte. Ubuntu hat sich daher z.B. von eCryptfs verabschiedet und es ist halt die Frage, ob man auf ein totes Pferd setzen sollte. Leider bietet Synology (noch) keine Alternative zu eCryptfs an.

Tommes

 

[Tommes]

Vielleicht eine zähneknirschende Kompromisslösung!

Man könnte das Passwort kurzzeitig in Klartext in der Auftragskonfiguration unter /var/packages/BasicBackup/target/ui/usersettings/backupjobs ablegen, was natürlich den Sinn einer Verschlüsselung absolut entgegenwirkt und von daher auch absolut inakzeptabel ist. Aber nehmen wir das für den Moment einfach mal so hin.

Als Passphrase würde sich z.B. die Seriennummer der DS anbieten. Diese lässt sich über einen Befehl einfach auslesen und müsste daher nirgendwo gespeichert werden.

Anhand des Passwortes und der Passphrase könnte man dann über das rsync-Script, welches ja bekanntlich mit root-Rechten läuft, eine Schlüsseldatei erstellen, die ich z.B. in /var/packages/BasicBackup/target/ui/usersettings/.secrets ablege, also auf der DS. Die Dateirechte würde ich soweit reduzieren, das nur root etwas damit anfangen könnte.

Wurde die Schlüsseldatei erfolgreich erstellt, könnte man das Passwort wieder aus der Auftragskonfiguration löschen. Somit würde das Passwort nur für die Zeit lesbar sein, bis das der Auftrag das erste mal ausgeführt wurde. Löschen lässt sich das Passwort ebenfall automatisch über das rsync-Script. Damit könnte man dann schon eher leben.

Wendet man die Zielordnerverschlüsselung jetzt ausschließlich auf externe Datenträger an, dann erhöht man die Sicherheit weiter, da man zum Entschlüsseln entweder die DS benötigt oder aber die Schlüsseldatei. Auf dem externen Datenträger selber würden so nur die verschlüsselten Daten liegen, auf der DS die passenden Schlüssel dazu.

Die Schlüsseldatei selber kann dann nochmal separat gesichert werden, ebenso wie die Passphrase, für den Fall, das man seine Daten auf einem anderen System entschlüsseln möchte. Für das manuelle einhängen würde ich eine entsprechende Anleitung zur Verfügung stellen.

Was haltet ihr von dieser Kompromisslösung?

Tommes

 

[Lord Helmchen]

Ich finde das klingt gut. Mein Ziel ist ja das Backup zu schützen. Wenn die NAS kompromittiert ist, muss das Backup nicht sicherer sein als die NAS selbst. Wenn das Klartext PW ggf. in einem verschlüsselten Ordner liegt sollte das ausreichen. Oder könnte man evtl. über die GUI einen "Dummy"-Share anlagen und verschlüsseln und diese Informationen für das Backup zu nutzen?

Was die Zukunft von eCryptfs angeht: ich glaube nicht, dass Synology das ersatzlos streichen wird. Ich könnte mir vorstellen, dass der Nachfolger dann auch von Apps nutzbar sein könnte. Anpassungen wären sicherlich notwendig, aber ich würde vermuten machbar.

Ich bin vom Hyper Backup gerade gefrustet, da ich zwei Jobs auf einer Ziel-HD habe. Und nach ein paar Läufen wird einer zerschossen und ist dann immer Offline. Ich finde dazu schon seit Jahren Berichte in Foren. das scheine Synology nicht zu interessieren.
Ein Öffnen in der File Station geht dann auch nicht mehr. Unabhängig davon muss man die Konfiguration für jeden Backup-Job einzeln anlegen. Und dann hoffen, dass man wenn man ein Ordner dazu kommt nicht vergisst diesen auch in beide Jobs einzutragen. Für ein Backup auf Wechselplatten ist das HB meiner Meinung nach nur sehr beschränkt geeignet. Für Onlinebackup (z.B. in OneDrive) funktioniert es gut.

Daher fände ich eine nutzbare Verschlüsselung in in Basic Backup sehr erstrebenswert, auch wenn man gewisse Kompromisse eingehen muss.

 

[Tommes]

Wenn das Klartext PW ggf. in einem verschlüsselten Ordner liegt sollte das ausreichen.

Das Klartext Passwort wird temporär im Auftrag abgelegt, bis das der Auftrag erstmalig ausgeführt wird. Danach wandert das Klartext Passwort von der Auftragskonfiguration in die Schlüsseldatei, welche mit der Passphrase verschlüsselt im System gespeichert wird. Das Klartext Passwort an sich wird anschließend aus der Auftragskonfiguration gelöscht.

Oder könnte man evtl. über die GUI einen "Dummy"-Share anlagen und verschlüsseln und diese Informationen für das Backup zu nutzen?

Würde das gehen, bräuchte ich den Zirkus mit dem Klartext Passwort nicht durchexerzieren. Also nein, das geht leider nicht.

Daher fände ich eine nutzbare Verschlüsselung in in Basic Backup sehr erstrebenswert, auch wenn man gewisse Kompromisse eingehen muss.

Ich schau mal, wie ich das alles umgesetzt bekomme, das es am Ende auch einfach und logisch aufgebaut ist. Hoffentlich stoße ich dabei nicht auf weitere Hürden.

Tommes

 

[Lord Helmchen]

Könnte man eigentlich einen eCryptFS Ordner auf der Externen Platte anlegen und mittels Scripten das (dis-)mounten machen und Basic Backup diesen Ordner für einen Job nutzen lassen? Dann würde ich ggf. darüber nachdenken solch ein Script selbst zu basteln und das mit Basic Backup zu kombinieren. Dann musst Du das mit der Commanline niemandem zumuten - dann mute ich das nur mir selbst zu.

 

[Tommes]

Hi!

Ich glaub, ich hab die ideale Lösung für dich gefunden. Hab das grade getestet und bei mir funktioniert das.

• Ggfl. einen neuen Basic Backup Auftrag erstellen. Backupziel -> USB-Datenträger.
• Die AutoPilot Funktion von Basic Backup einrichten und aktivieren.
• Einen USB-Datenträger einstecken und auf der Konsole der DS als root anmelden.
• Erstellen einer Schlüsseldatei (siehe nachfolgendes Script 1)
• Erstellen der autopilot Datei auf dem USB-Datenträger, wie in der Basic Backup Anleitung beschrieben.
• Die autopilot Datei editieren, den aktuellen Inhalt löschen und den Inhalt von Script 2 dort einfügen und anpassen.
• Die autopilot Datei ausführbar machen.
• USB-Datenträger über den DSM auswerfen und wieder einstecken.
• Nach dem erneuten Einstecken sollte folgendes passieren... (target steht symbolhaft für deinen Zielordner)
  • AutoPilot erkennt, das ein USB-Datenträger eingesteckt wurde, sich darauf ein Script namens autopilot befindet und führt dieses aus.
  • Der verschlüsselte Ordner /@target@ wird in den unverschlüsselten Ordner /target gemountet.
  • Das Backup wird ausgeführt und schreibt die Daten in den unverschlüsselten Ordner /target
  • Nach Beendigung des Backups wird der unverschlüsselte Ordner /target wieder getrennt und die Daten liegen verschlüsselt unter /@target@
  • Nach Bedarf kann der USB-Datenträger von AutoPilot wieder ausgeworfen werden.

Script 1: Erstellen einer Schlüsseldatei.
Da du ein Backup auf einen externen Datenträger machst, sollte die Schlüsseldatei auf einem internen Volume deiner DS abgelegt werden. Als Beispiel habe ich dafür den Ordner /volume1/NetBackup/.secrets ausgewählt. Als Passphrase wird die Seriennummer der DS eingetragen. Bei Bedarf kannst du aber auch einen beliebigen String dafür verenden. Du solltest ihn dir nur gut merken.
Das Script muss im Anschluss noch ausführbar gemacht werden (z.B. chmod 755 keyfile.key)

#!/bin/bash

# -----------------------------------------------------------------------------
# Teil 1: Erstellen einer eCryptfs Schlüsseldatei
# -----------------------------------------------------------------------------

# Pfad zur Schlüsseldatei
keypath="/volume1/NetBackup/.secrets"

# Dateiname der Schlüsseldatei
keyfile="keyfile.key"

# Paswwort
passwd="123456"

# Passphrase = Seriennummer der DS...
passphrase=$(cat /proc/sys/kernel/syno_serial)

# oder eigene Passphrase wählen
# passphrase="654321"

# -----------------------------------------------------------------------------
# Ab hier bitte nichts mehr ändern
# -----------------------------------------------------------------------------

# Falls keine Seriennummer gefunden wurde (z.B. bei Verwendung von VirtualDSM)
if [ -z "${passphrase}" ]; then
    echo "Es konnte keine Seriennummer ermittelt werden"
    exit 1
fi

# Falls nicht vorhanden, erstelle Pfad und Rechte zur Schlüsseldatei
if [ ! -d "${keypath}" ]; then
    mkdir -m 700 "${keypath}"
fi

# Erstelle die Schlüsseldatei im angegebenen Pfad und lege Dateirechte fest
if [ ! -f "${keypath}/${keyfile}" ]; then
    # Schlüsseldatei erstellen
    ecryptfs-wrap-passphrase "${keypath}/${keyfile}" "${passwd}" "${passphrase}"
    chmod 600 "${keypath}/${keyfile}"
fi

# Ergebnis
if [ -f "${keypath}/${keyfile}" ]; then
    echo "Schlüsseldatei: ${keypath}/${keyfile}"
    echo "Passwort: ${passwd}"
    echo "Passphrase : ${passphrase}"
    echo "Vorgang erfolgreich abgeschlossen"
else
    echo "Das Keyfile konnte nicht erstellt werden"
fi

Script 2: Inhalt der autopilot Datei
Hier musst du am Anfang die Variablen so anpassen, das diese mit den Inhalten aus Script 1 übereinstimmen. Also Pfad und Name der Schlüsseldatei und vor allem das Backupziel, welches du im zugehörigen Basic Backup Auftrag angegeben hast. Beispielhaft habe ich hier volumeUSB1/usbshare1-1/Backup eingetragen. Ebenfalls musst du noch deinen Backupauftrag aus Basic Backup dort eintragen. Beispielhaft habe ich dort bash /usr/syno/synoman/webman/3rdparty/BasicBackup/rsync.sh --job-name="eCryptfs auf USB" eingetragen. Das Script muss im Anschluss ebenfalls ausführbar gemacht werden (z.B. chmod 755 autopilot)

#!/bin/bash

# -----------------------------------------------------------------------------
# Teil 2: Einhängen und trennen eines eCryptfs Verschlüsselten Ordners
# -----------------------------------------------------------------------------

# Unverschlüsselter Zielordner der Datensicherung
target_folder="/volumeUSB1/usbshare1-1/Backup"

# Pfad zur Schlüsseldatei
keypath="/volume1/NetBackup/.secrets"

# Dateiname der Schlüsseldatei
keyfile="keyfile.key"

# Passphrase = Seriennummer der DS...
passphrase=$(cat /proc/sys/kernel/syno_serial)

# ...oder eigene Passphrase wählen
# passphrase="654321"

# Basic Backup Auftrag
function run_backupjob ()
{
    bash /usr/syno/synoman/webman/3rdparty/BasicBackup/rsync.sh --job-name="eCryptfs auf USB"
}

# -----------------------------------------------------------------------------
# Ab hier bitte nichts mehr ändern
# -----------------------------------------------------------------------------

function decrypt_target ()
{
    # Unverschlüsselten Zielordner anlegen, falls nicht vorhanden
    if [ ! -d "${target_folder}" ]; then
        mkdir -p "${target_folder}"
    fi

    # Aus dem unverschlüsselten Zielordner ${target_folder} einen verschlüsselten @target_folder@ generieren
    encrypted_target_folder=$(echo "${target_folder}" | sed 's/\/\([^/]*\)$/\/@\1/' | sed 's/\\//g;s/$/@/')

    # Verschlüsselten Zielordner anlegen, falls nicht vorhanden
    if [ ! -d "${encrypted_target_folder}" ]; then
        mkdir -p "${encrypted_target_folder}"
    fi

    # Prüfen, ob der unverschlüsselte Zielordner existiert
    if [ -d "${target_folder}" ]; then

        # Prüfen, ob der unverschlüsselte Zielordner bereits eingehängt ist
        if [[ "$(/bin/mount -t ecryptfs | grep "${target_folder}" | wc -c)" -ne 0 ]]; then
            # Trenne unverschlüsselten Zielordner
            /bin/umount "${target_folder}"
        fi

        # Prüfen, ob der unverschlüsselte Zielordner leer ist
        if [ -z "$(ls -A "${target_folder}")" ]; then

            # Mit Hilfe der Passphrase das Passwort aus der Schlüsseldatei auslesen
            keyfile_passwd=$(ecryptfs-unwrap-passphrase "${keypath}/${keyfile}" "${passphrase}")

            # Verschlüsselten Ordner nach ${target_folder} mounten
            yes "" | /bin/mount -t ecryptfs "${encrypted_target_folder}" "${target_folder}" -o key=passphrase:passphrase_passwd="$keyfile_passwd",ecryptfs_cipher=aes,no_sig_cache,ecryptfs_key_bytes=32,ecryptfs_passthrough=n,ecryptfs_enable_filename_crypto | grep ecryptfs_sig= | sed 's/.*ecryptfs_sig=//'
        else
            exit 1
        fi
    fi
}

function encrypt_target ()
{
    # Unverschlüsselten Zielordner trennen
    /bin/umount "${target_folder}"
    sleep 5
    rm -r "${target_folder}"
}

# -----------------------------------------------------------------------------
# Ausführung
# -----------------------------------------------------------------------------

# Zielordner einhängen
decrypt_target
sleep 5

# Basic Backup Auftrag ausführen
run_backupjob
sleep 5

# Zielordner trennen
encrypt_target

exit ${?}

Das war's. Schau mal, ob du damit zurechtkommst, ansonsten meld dich gerne. Es sei aber noch angemerkt, das du das alles auf deine eigene Verantwortung ausführst und ich für keinerlei Schäden oder Datenverlust verantwortlich gemacht werden kann. Bestenfalls testest du das vorher ausgiebig und setzt dich ein wenig mit den Scripten auseinander, um zu verstehen, was da genau passiert.

Viel Erfolg

Tommes

 

[Lord Helmchen]

Cool. Vielen Dank! Das geht mit dem aktuellen Basic Backup, oder brauche ich da eine neuere Version?

 

[Tommes]

Das funktioniert mit der aktuellen Version von Basic Backup. Die AutoPilot Funktion, zum automatischen Starten von Scripten auf externen Datenträgern ist bereits intrigiert. Du brauchst demnach nur eine Schlüsseldatei zu erstellen und dann das autopilot Script wie oben beschrieben, modifizieren.

Falls du Unterstützung brauchst, meld dich gerne.

 

[Lord Helmchen]

Super. Ich denke ich werde das morgen ansehen und ausprobieren.

Funktioniert das mit dem AutoPoliten auch, wenn ich auf das selbe Medium zwei (oder mehr) Backup-Jobs schreibe? Gibt es ggf. einen Unterschied zwischen verschlüsselten und unverschlüsselten Jobs? Also beispielsweise: Automount, alle Jobs laufen und nach dem letzten wird die Platte unmounted?

Das Du für die Sonderlocke nicht mehr haftest als für den Rest ist schon klar.

 

[Tommes]

Du kannst in der autopilot Datei theoretisch auch mehrere Aufträge hintereinander ausführen. Praktisch habe ich das noch nicht getestet, sollte aber funktionieren. Du kannst dabei jedoch nur einen verschlüsselten Ordner einhängen und trennen, da weder die autopilot Datei, noch die o.a. Scripte für eine Mehrfachausführung ausgelegt sind. Im Grunde würde das dann so ablaufen…

• USB-Datenträger wird erkannt.
• AutoPilot Script hängt z.B. den verschlüsselten Ordner /@Backup@ ein
• AutoPilot führt den ersten Basic Backup Auftrag aus und sichert z.B. nach /Backup, also dem unverschlüsselten Ordner.
• Nach Beendigung des Auftrages führt AutoPilot den nächsten Auftrag aus, sichert diesmal aber in den Ordner /MeinBackup
• … und anschließend der nächste Auftrag… usw.
• Nach dem Abarbeiten aller Aufträge schließt AutoPilot den verschlüsselten Ordner wieder und wirft auf Wunsch den USB-Datenträger aus.

Aber wie so oft, gilt auch hier das Motto: es gibt nichts gutes, außer man tut es. Mach dir also ein paar Gedanken, wie es funktionieren könnte und probiere einfach aus. Erzählen kann ich ja viel, am Ende musst du das aber umsetzten und zufrieden mit der Lösung sein.

 

[Lord Helmchen]

Vielen Dank! Zwei Jobs, ein verschlüsselter und ein unverschlüsselter sollten ausreichen. Ich setze mich gleich mal ran Deine Scripte zu verstehen.

 

[Lord Helmchen]

Ich habe noch eine Frage: mir ist der Unterschied zwischen "passwd" und "passphrase" nicht klar.

Spricht etwas dagegen, die auf beides auf das selbe (sicherere) Passwort zu setzen? Dass ich das natürlich sicher ablegen muss, damit im falle eines Crash das Recovery durchführen kann, ist klar.

Ergänzung: sehe gerade, dass die passphrase auch im Autopilot Script steht. Also natürlich nicht auf den selben Wert (wäre dann ja witzlos zu verschlüsseln)

 

[Tommes]

Die Passphrase schützt die Schlüsseldatei, welche das Passwort für den verschlüsselten Ordner beinhaltet. Es kann ja jeder machen, wie er mag, aber ich würde definitiv nicht zweimal dasselbe Passwort dafür verwenden. Anhand der Passphrase lässt sich die Schlüsseldatei auslesen und somit das Passwort. I.d.R. setzt man als Passphrase einen langen und komplexen String ein, ich habe aber irgendwo gelesen, das die Passphrase nicht länger als 64 Zeichen lang sein soll.

Wie dem auch sei... ich benötige die Schlüsseldatei, um das ganze automatisiert ablaufen zu lassen und dem Ganzen ein wenig Sicherheit zu geben. Wenn du zweimal das Gleiche Passwort vergibst, untergräbst du dir die eigene Sicherheit.

 

[Lord Helmchen]

Prima! Das Backup funktioniert. Ich kann jetzt auch wie von Dir beschreiben zwei Jobs nacheinander laufen lassen. Mein Problem ist jetzt, dass das Autoplay nicht funktioniert. Ich habe die ext. HD per E-SATA angeschlossen. Auf der Platte (nach dem Mounten in /volumeSATA/satashare) liegt die Datei autopilot (-rwxr-xr-x ]...] autopilot).

Wenn ich die Datei mittels sudo von Hand starte, läuft das Backup. Aber Anschließen der Platte bewirkt nichts. In Basic Backup habe ich den autopiloten aktiviert.

 

[Tommes]

Aus Mangel an E-SATA Datenträgern kann ich das bei mir leider nicht testen. Was sagt denn das AutoPilot Protokoll. Du findest das Protokoll in Basic Backup oben in der Navigationsleiste unter Protokolle -> AutoPilot Protokoll.

 

[Lord Helmchen]

Das Protokoll ist leider leer.

 

[Tommes]

Du hast AutoPilot aber schon aktiviert, so wie es in der Anleitung steht?