Beim ersten Versuch sind nach dem Neustart auch bei mir bei beiden NAS diverse Icons verschwunden
So was hatte ich gelegentlich nach Firmwareupdates auch schon. Es hat dann immer gereicht, die Icons aus der Liste der Anwendungen (Dreistrichmenü oben links), wo sie weiterhin vorhanden waren, wieder auf die Schreibtischoberfläche zu ziehen.
Jedenfalls muss das NAS wie o.a. SOFORT aus dem Internet.
Das kann hier missverständlich sein.
Es ist kein Problem, wenn das NAS von sich aus auf das Internet zugreifen kann (z. B. um nach Firmwareupdates zu schauen oder um ein Backup auf einen anderen Server anzustarten).
Was man aber vermeiden sollte, und was mit dolbyman s und FSC830 s Bemerkung gemeint ist, ist ein Zugriff von außen auf das NAS. Wenn Portfreigaben diesen Zugriff ermöglichen, besteht ein potentielles Risiko. Ein Zugriff über VPN ist sicher, über ssh kann das ebenfalls sicher sein (wenn man es richtig macht), ansonsten sollte man sehr genau wissen, was man da macht und freigibt.
Wenn du deine Webseiten und Google Drive über ein Skript, das auf dem NAS läuft (z. B. mit Curl, wget, rsync o. Ä.) sicherst, dann bist du auf der sicheren Seite. Wenn der Sicherungsjob auf deinem Webserver oder bei Google läuft, dann hast du eine Sicherheitslücke, die eventuell gravierend sein kann.
Genau das ist der Fall. Die Verschlüsselung der Dateinamen belegt Platz und verringert die maximale Namenslänge.
Ich weiß ja nicht, aber wenn Du SMB auf dem NAS verwendest
Meinst du mich oder Austro-Diesel ?
Egal, mit Apple oder SMB hat das nichts zu tun, sondern es geht um einen Synchronisationsjob von NAS zu NAS.
Das ewige Problem mit zu langen Datei- \ Pfadnamen.
Nein, eigentlich nicht. Bisher gab es bei zu langen Dateinamen eine Warnung, die Datei wurde übersprungen, also nicht synchronisiert, aber der Job hat dann normal weiter gemacht und sich regulär beendet.
Jetzt beendet sich der Job nicht mehr regulär, sondern startet sich neu und verursacht damit eine Endlosschleife.
Die Dateien werden übrigens von einem Programm erzeugt. Ich habe auch keine Kontrolle über den Dateinamen, kann da also nicht eingreifen. Das ist eigentlich auch nicht schlimm, weil das temporäre Dateien sind, und ob die synchronisiert werden oder nicht, ist mir egal. Aber jetzt setzen sie den Job außer Gefecht.
Könnte es sein, dass durch das Update der Pfad um das eine oder andere Zeichen verlängert wurde und deshalb nun nicht mehr funktioniert?
Nein.
Wäre aber auch egal. Ich hatte vorher auch immer mal wieder zu lange Dateinamen, aber da gab es nur eine Warnung, und gut war's.
Hmm, müssten dies nicht min. 255 Zeichen oder so sein?
Unverschlüsselt ja, aber mit ecryptfs-verschlüsselten Dateisystemen bleiben 143 Zeichen, von denen noch etwa 7 Zeichen abzuziehen sind für temporäre Dateinamensänderungen des rsync-Prozesses.
Jetzt habe ich doch noch einen Fehler mit dieser Firmware gefunden:
Wenn man in HBS einen Synchronisationsjob zu einem anderen NAS per rsync hat, und eine Datei kann nicht übertragen werden, weil der Dateiname zu lang ist (das kann vorkommen, wenn man von einem unverschlüsselten Quell-Volume auf ein verschlüsseltes Ziel-Volume überträgt, weil es dann im Ziel eine Begrenzung der Dateinamenlänge auf etwa 143 Zeichen gibt), dann gerät der Job in eine Endlosschleife. Der Job erreicht 100%, erkennt, dass eine Warnung vorliegt und nicht alle Dateien übertragen wurden und startet sich erneut, um die fehlende Datei auch zu übertragen. Das kann natürlich nicht funktionieren, weil der Dateiname immer noch zu lang ist.
Man könnte meinen, das liege an HBS, aber der Fehler tritt auch mit HBS vom April 24 auf, und die Version hatte bisher den Fehler definitiv nicht. Erst mit der neuen qts-Version tritt das auf.
Hat von euch auch auch jemand den Fehler?
Ich werde ein Ticket aufmachen.
Verschiebe ich nun mit Filestation (via Webbrowser) große (ISO/Multimedia/VM-)Dateien von einer Freigabe zur anderen bekomme ich ca. 50- (im kurzen Idealfall) 100 MB/s. Oft auch unter 50 MB/s.
Befinden sich die beiden Freigaben auf derselben physischen Platte?
Wenn ja, dann ruinieren dir die vielen Kopfbewegungen die Geschwindigkeit.
/root liegt auf der Ramdisk. Damit ist das Verzeichnis nach jedem Reboot weg. Du kannst das Verzeichnis /root/.local/zoxideoderwiedasheisstnach der Installation einmalig in ein permanentes Verzeichnis kopieren und in autorun.sh wieder in der Gegenrichtung zurückkopieren. Denk an die Beibehaltung der einzelnen Dateirechte (insbes. x-Bit).
Zu ~admin/.bashrc kann ich nichts sagen. ~admin/.profile überlebt einen Reboot und bleibt erhalten.
Das würde ich gerne ändern:
Du hättest besser ein neues Thema aufmachen sollen, weil das nichts mit der ursprünglichen Frage zu tun hat.
Ändern kannst du die Datei gerne, aber es bewirkt nichts. Das Problem ist, dass die Konfigurationsdatei bei jedem Start des Dämonen neu zusammengebaut wird und damit alle Änderungen in der Datei überschrieben werden. Wenn deine Änderungen aktiv werden sollen, wird es kniffelig, insbesondere wenn die Änderungen auch einen Reboot überleben sollen (Datei in autorun.sh ändern hilft nicht).
Lösungsmöglichkeiten:
1. Die Dateien ändern, aus denen die SSH-Konfigurationsdatei beim Start des Dämonen zusammengebaut wird.
Ich weiß nicht, welche Dateien das sind, und diesen Weg habe ich nicht weiter verfolgt.
2. Man jubelt dem Dämonen den Pfad zu einer eigenen Konfigurationsdatei unter.
Dazu kopiert man die Datei /etc/ssh/sshd_config
in ein Verzeichnis, das schon zum Boot-Zeitpunkt zur Verfügung steht (ich habe /mnt/HDA_ROOT/boot genommen) und ändert sie nach Belieben ab.
In /etc/daemon_mgr.conf befindet sich eine Liste von Dämonen inklusive ihrer Aufrufparameter. Diese ändert man in autorun.sh (oder in einer aus autorun.sh aufgerufenen Batchdatei, das ist flexibler) so, dass für ssh unsere Konfigurationsdatei als Parameter eingetragen wird, und startet den ssh-Dämonen neu. Das ergibt folgenden Code, der dort eingetragen wird:
cp -p /etc/daemon_mgr.conf /etc/daemon_mgr.conf.bak
sed '/^DAEMON[0-9]* = sshd,.*$/s/-f *[^ ][^ ]* /-f \/mnt\/HDA_ROOT\/boot\/sshd_config /' /etc/daemon_mgr.conf.bak >/etc/daemon_mgr.conf
killall sshdNach dem nächsten Reboot nutzt der ssh-Dämon unsere Konfigurationsdatei. Wenn man nicht auf den Reboot warten will, führt man die drei Kommandos mit sudo per Hand aus.
Bei der Gelegenheit kann man in die neue ssh-Konfigurationsdatei die Authentifizierung ausschließlich per ssh-Key einschalten (Authentifizierung per Passwort ausschalten) und die Liste der zulässigen Benutzer setzen.
Wenn man Murks macht und nicht mehr ins System kommt, muss man Telnet einschalten und sich darüber einloggen (bitte nur im eigenen LAN; Telnet ist sehr unsicher).
Du scheinst einen anderen Nutzer (alternativer Admin) zu verwenden.
Das ist kein Problem. Mit sudo -i bekommt man jederzeit eine vollwertige Admin-Shell. Nur für Telnet ist der echte Admin unverzichtbar.
Adjusted the default settings for NFS host access to enhance the security of NFS exports.
Da wüsste ich mal gerne, was dahinter steht.
Das Sicherheitscenter meldet "hohes Risiko", weil ich nicht die neueste Firmware installiert habe. Tatsächlich ist heute eine neue Firmware[...] veröffentlicht worden.
Der freundliche Herr vom Qnap-Support meinte mal, er installiere kein Betriebssystem, dass nicht seit wenigstens einem halben Jahr veröffentlicht sei.
Ganz so lange warte ich nicht, aber das "hohe Risiko" sehr ich eher bei Installation einer Firmware am Tage des Erscheinens.
Die Größe von 320MB ist normal. Und da sollte ein Update auch gehen, ohne die Ramdisk vergrößern zu müssen.
Ich wüsste auch nicht, wie man da was aufräumen könnte. Allenfalls unter /var/log kann man aufräumen, aber das bringt nicht viel.
Es gibt eine Sicherheitsinfo.
Alle Lücken sind mit dieser Bedingung
If a remote attacker gains access to an administrator account
Wenn der Angreifer Zugriff auf den Admin-Zugang hat, ist dann nicht ohnehin alles verloren?
kann man das Volllaufen wegen zu großen Logfiles im System unterbinden?
So ganz "legal"? Nein, das muss Qnap machen.
Man kann natürlich mal nachschauen, warum ein Logfile so groß wird. Es kann auch ein echtes Problem dahinter stecken.
Was man notfalls machen könnte:
die UID ist aber definitiv an mehreren Stellen im System zu finden
Nein, nicht die UID im System ändern, sondern die auf der Platte mit
# Beispiel, statt sda1 natürlich die passende Platte, und natürlich die UID der alten Platte
tune2fs /dev/sda1 -U 266584be-d7b7-11eb-8c76-c3eef48c7257Zu voll ist bei dir nur /mnt/HDA_ROOT und da kann admin/root drauf schreiben bzw. löschen. Schau dort mal nach.
Was ergibt
sudo du -h --max-depth 1 /mnt/HDA_ROOTBei mir sind es in der Summe 217MB.
Und wenn man die UID gleich mitkopiert, d. h. auslesen in der alten und setzen in der neuen Platte?
Siehe hier für die Kommandos.
Es müsste doch eigentlich auch möglich sein, man hängt beide Platten, die alte und die neue, an einen Linux-Rechner oder Mac und kopiert mit dd die alte Platte komplett auf die neue Platte. Anschließend baut man die neue Platte ins NAS ein und erweitert das Volume.
Hat das schon mal jemand ausprobiert?
Es gäbe jetzt zwar die Möglichkeit, alle Dateien zu kopieren, das System komplett zu leeren und neu aufzusetzen. Aber mal von der Zeit abgesehen, habe ich halt keinen Platz für alles (dafür hat man ja einen Netzwerkspeicher
Tu dir einen gefallen, kauf dir eine USB-Platte, die groß genug ist, und mach ein Backup. Ansonsten musst du irgendwann mit einem Totalverlust der Daten rechnen.
Der Netzwerkspeicher enthebt dich nicht von der Pflicht, ein Backup machen zu müssen. Daten, deren Verlust nicht jederzeit verschmerzt werden kann, müssen auf mindestens zwei Orten gespeichert sein, entweder PN und NAS (dann ist das NAS das Backup) oder NAS und ein weiterer Speicher wie eine USB-Festplatte. Wenn die Daten sich ausschließlich auf dem NAS befinden, dann sind sie nicht gegen Hardware-Ausfälle oder eigene Dummheit geschützt.
--
Dann konkret zu deinem aktuellem Problem:
Kennst du dich mit ssh und der Unix-Shell aus? Dort kannst du auch Verzeichnisse und Dateien sehen, die sich in nicht freigegebenen Ordnern befinden. Das dürfte dir helfen, deine verschwundenen Daten wiederzufinden.
Für mich sieht das nach einem Fehler auf Dateisystemebene aus, und daher würde ich das Dateisystem prüfen und gegebenenfalls reparieren. Über die GUI siehe hier, ansonsten gibt es e2fsck in der Shell. Letzteres habe ich auf dem NAS nicht ausprobiert, da bisher kein Bedarf, also ohne Gewähr. Mach in jedem Falle vorher ein vollständiges Backup, sofern du es noch nicht hast, denn das geht auch bei einem Read-Only-Dateisystem.
