Beiträge von tgsbn

  • Netzwerkzugriff (SMB) funktioniert mit Brother MFC-L8690CDW nicht

    Ich kann beitragen, dass bei mir mit einem alten Brother MFC-J6520DW Scan-to-SMB einwandfrei und problemlos funktioniert.

    Auf dem NAS habe ich "Lowest SMB Version: SMB 2" und "Highest SMB Version: SMB 3" eingestellt, d.h. SMB 1 ist nicht aktiv.

    Für den Scanner habe ich ein eigenes Benutzerkonto "Brother", das nur auf die Scan-Freigabe Zugriff hat.

    Wie ich das damals step by step eingerichtet habe weiß ich nicht mehr, dafür ist das zu lange her.

    Aber ich erinnere mich an keine besonderen Hürden, also muss es wohl recht einfach gewesen sein.

  • Läuft Reparaturbefehl via SSH auf NAS weiter wenn PC ausgeschaltet wird?

    Nee, da ist keine virtuelle Konsole im Einsatz und auch kein cron-task.

    Der Reparaturbefehl e2fsck_64 läuft direkt auf dem ssh-Terminal und würde somit abgebrochen, wenn putty beendet wird.

    Es wäre von Seiten des QNAP-Supports vielleicht klug gewesen, dir zu sagen, dass nicht nur das NAS, sondern auch der PC anbleiben sollte.


    Ich halte dir (und dem QNAP-Techniker) die Daumen, dass die Reparatur erfolgreich ist.

  • NAS nicht erreichbar über LAN

    Wenn der Zugriff auf die Weboberfläche bei gestecktem LAN-Kabel klappt und nur der SMB-Zugriff nicht, kann das Problem eigentlich nichts mit IP-Adressvergabe und Routing zu tun haben.


    Wie äußert sich denn das "geht es nicht" genau?

    Wie verbindest du dich mit dem freigegebenen Dateisystem?

    Per Windows Explorer oder per Kommandozeile?

    Durch Navigieren zum UNC-Pfad oder mit dem Freigabeassistenten?

    Gibst du das NAS per Name oder per IP-Adresse an?

    Bekommst du eine Fehlermeldung?

    Wie lautet die?

  • Qnap ändert selbständig Pfade im Docker Container

    Die Pfade /share/external/VOLUME_NAME sind Symlinks, die von QTS beim Mounten einer externen Festplatte angelegt und beim Unmounten (meistens) wieder gelöscht werden.

    Ich könnte mir vorstellen, dass die Container Station irgendwie erkennt, wenn der Pfad nicht existiert, und dann eine automatische Reparatur versucht, die von bei dir nicht zutreffenden Voraussetzungen ausgeht.

  • Probleme mit FileStation 5.5.6.4715

    Zitat von Mavalok2

    Ähm, beim "Verschieben" sollten die Dateien nicht umbenennt werden. Dann wäre dies vorher ein Fehler gewesen.

    Das ist eine Frage der Nomenklatur.

    Grundsätzlich gibt es bei fast allen aktuell üblichen Dateisystemen zwei Möglichkeiten, eine Datei innerhalb desselben Dateisystems von einem Ordner in einen anderen zu "verschieben".

    1. Man kopiert sie vom alten in den neuen Ordner und löscht sie im alten.

    2. Man lässt die Daten wo sie sind und ändert nur die Verzeichniseinträge, so dass die Datei im neuen statt im alten Verzeichnis erscheint.

    Option 2 wird vielfach als "umbenennen" bezeichnet auch wenn streng genommen der Name nicht geändert wird, sondern nur der Pfad.

    So z.B. vom Linux-Kommando mv:

    Code
    tilman@Neon:~$ mv -v Musik/bach-id3.out .
Datei umbenannt 'Musik/bach-id3.out' -> './bach-id3.out'
tilman@Neon:~$ LANG=C mv -v bach-id3.out Musik/
renamed 'bach-id3.out' -> 'Musik/bach-id3.out'
tilman@Neon:~$

  • USB Festplatte wird im zweiten Anlauf nicht erkannt

    Zitat von Mavalok2

    Im Moment fällt mir leider nichts anderes ein als auf die Kompatibilitätsliste von QNAP zu verweisen.

    Das wird meiner Meinung nach nichts bringen. Die USB-Massenspeicherschnittstelle ist sehr gut standardisiert, da gibt es quasi keine Inkompatibilitäten. Die QNAP-Kompatibilitätsliste ist nur interessant, wenn man einen Support Case bei QNAP aufmachen will. Und der wird bei dem beschriebenen Szenario so oder so sagen: "Keine unterstützte Betriebsart." Egal ob die Platte auf der Kompatibilitätsliste steht oder nicht.

    Zitat von Mavalok2

    So etwas [Trennen der Stromversorgung im Betrieb] kann eine mechanische Festplatten killen. Damit nimmst Du der Festplatte die Möglichkeit den Lese-/Schreib-Kopf in die Parkposition zu bringen. Früher oder später macht dies die Festplatte bzw. der Kopf oder die Oberfläche nicht mehr mit. Gerade bei externen HDDs ist dies nochmals wichtiger.

    Moderne Festplatten nutzen die Restenergie der Plattenrotation, um bei Verlust der Versorgungsspannung die Köpfe noch zu parken.

    Zitat von Ich bins

    Ich habe noch zwei weitere USB-Gehäuse hier, darunter auch ein WD Elements, aber da blendet HBS die Option aus, dass es automatisch startet, wenn die Platte erkannt wird. Ein drittes lässt sich nicht einbinden.

    Das kommt mir doch irgendwie bekannt vor.

    Schau mal, während das Elements-Gehäuse nicht angeschlossen ist, im Control Panel > Privilege > Shared Folders, ob es da trotzdem noch als Shared Folder gelistet ist.

    Wenn ja, lösche es. (Nur die Freigabe, nicht die Daten, an die kommt das NAS eh nicht dran, wenn die Platte gar nicht angeschlossen ist.)

    Normalerweise sollte QTS die Freigabe automatisch beim Auswerfen der Platte entfernen.

    Aber bei mir hat es das mal vergessen, und das hatte dann genau diesen Effekt zur Folge, dass der automatische Start und das automatische Auswerfen nicht mehr angeboten wurde.

  • HBS3: neuer Fehler

    Zum einen passt das von meiner Auslagerungspolitik her gut zusammen.

    Und zum anderen habe ich keinerlei Anhaltspunkte dafür, dass durch eine Trennung irgendetwas besser würde.

  • HBS3: neuer Fehler

    Problem gelöst

    (Vielleicht, zumindest zum Teil, mal sehen...)

    Im QTS Control Panel > Shared Folders war die Sicherungsplatte Tosh1T als Shared eingetragen, obwohl sie nicht angeschlossen war.

    QTS macht das aus unerfindlichen Gründen bei jeder USB-Platte, die man anschließt, dass es die dann auch gleich im Netz freigibt.

    Normalerweise entfernt es die Freigabe dann beim Auswerfen auch wieder.

    Bei dieser Platte hat das offenbar bei einer der letzten Sicherungen nicht richtig geklappt, so dass die Freigabe stehen blieb, obwohl ihr Pfad /share/external/DEV3301_1 gar nicht mehr existierte.

    Die Folge war, dass

    a) HBS die Platte offenbar für fest verbaut hielt und für sie die Optionen "Auto-backup" und "Eject after completion" nicht mehr anbot

    b) bei jeder anderen USB-Platte, die ich anschloss, deren erste Partition als Volume "Tosh1T" im System auftauchte und damit den HBS-Jobstart für dieses Volume auslöste.


    Nachdem ich die Freigabe (ohne angeschlossene USB-Platte) entfernt hatte, waren die fehlenden Job-Optionen in HBS wieder da.

    Und als ich dann eine der anderen Platten anschloss, wurde auch wieder nur deren zuständiger HBS-Job gestartet.

    Der Auswurf am Jobende hat zwar wieder nicht funktioniert, aber das ist vielleicht ein separates Problem.

    Warum die Freigabe stehengeblieben war, weiß ich auch nicht und kann nur hoffen, dass das nicht so oft passiert.

  • HBS3: neuer Fehler

    Es wird immer bunter.

    Auch der Anschluss der nächsten Platte startete wieder zusätzlich zum richtigen Job einen falschen, der dann mit "failed to locate destination folder" abbrach.

    (Ja, ich habe in den drei Wochen zwischen dem Ausgangsposting bis jetzt kein Backup gemacht - Schande über mich!)

    Hinzu kam diesmal, dass auch die Option "Eject after completion" nicht funktionierte, die Platte blieb nach Ende beider Jobs weiter eingehängt.


    Weitere Untersuchung per ssh ergab, dass in /share, wo QTS normalerweise beim Anschließen einer externen Platte für jede Partition einen Symlink mit dem Namen des Partitionslabels auf deren Mountpoint in /share/external anlegt und beim Auswerfen wieder entfernt, totales Chaos herrschte:

    • Die angeschlossene Sicherungsplatte hat drei Partitionen:
      "WIMAGE-BOOT" (FAT32) für c't-WIMage
      "WIMage-Daten" (NTFS) ebenfalls für c't-WIMage
      "Elements2T" (ext4) für die HBS-Sicherung
    • Für die ersten beiden wurden korrekte Symlinks in /share angelegt:
      WIMAGE-BOOT -> external/DEV3301_1/
      WIMage-Daten -> external/DEV3301_2/
    • Zusätzlich wurde für die erste Partition noch ein zweiter Symlink angelegt:
      Tosh1T -> external/DEV3301_1
      "Tosh1T" ist der Name der nicht angeschlossenen Sicherungspartition, für die dann auch der Job fälschlich gestartet wurde und wegen fehlender Zielordner abbrach.
      (Konsequenterweise zeigte die QTS File Station ein Volume Tosh1T mit demselben Inhalt wie WIMAGE-BOOT an.)
    • Für die dritte Partition wurde kein Symlink angelegt, sondern stattdessen ein Verzeichnis mit dem Namen "Elements2T", in dem dann auch das Backup landete:
      Elements2T/
      Da /share als tmpfs gemountet ist, landete mein Backup also in einer Ramdisk. =:-O
      (In der QTS File Station erschien sie aber trotzdem mit dem korrekten Inhalt - das verstehe, wer will.)

    In Summe gab es also zwei Symlinks auf die erste Partition, einen auf die zweite und gar keinen auf die dritte.

    Nachdem ich die USB-Platte von Hand ausgeworfen habe, verschwanden neben den Mountpoints unter /share/external auch die beiden korrekten Symlinks für die NTFS-Partitionen.

    Der falsche Eintrag Tosh1T -> external/DEV3301_1 blieb als dangling symlink stehen, und in der File Station wurde auch weiterhin ein Volume "Tosh1T" angezeigt, beim Anklicken erschien aber die Meldung:

    pasted-from-clipboard.png

    Auch der Ordner "Elements2T" mit meiner Sicherung blieb in /share liegen.


    Irgendetwas geht da mit der Verwaltung von External Volumes ganz fürchterlich schief.


    Update:


    Ich wollre versuchen, bei dem Job für die Platte "Tosh1T", der immer fälschlich mitgestartet wird, die Option "Auto-backup" rauszunehmen.

    Aber die HBS3-Oberfläche zeigt an, dass er auf "No schedule" stehen würde.

    Die Option "Auto-backup wird" gar nicht angeboten. (Ist aber aktiv, wenn ich die Platte anschließe, wird der Job gestartet.)

    Auch die Checkbox "Eject after completion" fehlt.

    Als ob HBS3 gar nicht merken würde, dass das eine USB-Festplatte ist.


    Weiß jemand, wo HBS3 diese Einstellungen speichert?

    Kann ich den Job irgendwie neu anlegen, ohne die alten Backups zu verlieren?

    (Ja, ich habe die Suchfunktion des Forums benutzt. Ergebnislos.)

  • Admin Login Failures von ::1 durch Security Checkup?

    Ich habe (wahrscheinlich? vielleicht?) die Ursache gefunden.

    Im Security Center auf dem Reiter Security Checkup steht neben der Überschrift ein oranges Warndreieck mit dem Text "Unavailable".

    Wenn man da draufklickt, erscheint der Popup-Text:

    Code
    Security Center failed to run the scheduled scan because the current Log On As account session expired. To
resolve the issue, go to "Scan Schedule" and reapply the schedule settings.

    Würde ja passen, hinreichend schlampige Programmierung vorausgesetzt:

    Das Security Center stößt auf den Fehler "session expired" und probiert es einfach nochmal, 138-mal hintereinander, vielleicht geht das "expired" ja von alleine weg.

    Und das QuLog Center loggt "session expired" durch den eigenen Security Checkup mit genau derselben Meldung wie einen Passwortrateversuch von außen.


    Schön auch, dass auf der Übersichtsseite unter Security Checkup trotzdem alles grün ist.

    Der (grüne) Text "No risk detected" (Müsste ich das nach Forenregeln eigentlich als Zitat formatieren?) ist natürlich streng genommen nicht falsch.

    Aber trotzdem finde ich es etwas, nunja, merkwürdig, wenn das Ergebnis "Prüfung konnte nicht durchgeführt werden" an dieser Stelle zur gleichen Anzeige führt wie "geprüft, kein Risiko gefunden".


    Ich habe jetzt wie empfohlen den Scan Schedule geöffnet und einfach ohne irgendetwas zu ändern "Apply" geklickt.

    Das orange Dreieck ist jetzt weg.

    Mal sehen, was beim nächsten Durchlauf passiert.