Wenn du auf den Freigabeordner hauptsächlich von Linux aus zugreifst, kannst du ihn auch per nfs einbinden. Die Syntax in fstab ist dann eine andere. (Beim Wechsel zwischen nfs und smb gibt es hingegen gerne mal Rechteprobleme.)
Ansonsten mal in qts (im Browser) in Systemsteuerung ⇒ Berechtigung ⇒ Freigabeordner prüfen, ob dein Benutzer "ich" die nötigen Rechte auf den Freigabeordner hat.
Euer Vergleich von Windows und Qnap lenkt ab. Bei Windows greift man nur vom PC aus auf das Internet zu, aber nie vom Internet auf den PC. Solange man nur das macht, ist das Qnap NAS wesentlich weniger gefährdet, da man ein NAS nicht zum Surfen verwendet, sondern nur für wenige restriktive Operationen wie Abfrage nach neuen Firmwareversionen oder Erstellung von Außer-Haus-Backups.
Aber man möchte auch gerne von außen auf das NAS zugreifen können, z. B. um im Urlaub auf die heimische Videothek zuzugreifen oder um Fotos vom Handy sofort im NAS zu speichern. Das sind Dinge, die man bei Windows nie wagen würde. Wenn man das zulässt, kann bei Sicherheitslücken (durch Software oder durch falsche Konfiguration) potentiell ein Fremder ohne Wissen des NAS-Besitzers auf das NAS zugreifen. Diese Dienste sollte man nur über VPN freigeben und nutzen, es sei denn, man weiß genau, was man macht.
Die ganzen SMB-Einstellungen haben aber nur dann eine Abhängigkeit zur Fritz-OS-Version, wenn auf den SMB-Speicher der Fritzbox (intern oder an angehängter USB-Festplatte) zugegriffen wird.
Bist du dir sicher, dass der Receiver sich per LAN-Kabel mit der Fritzbox verbindet und nicht per WLAN?
Beim WLAN sind nämlich mit Fritz OS 7.20 ein paar alte und mittlerweile unsichere Protokolle abgeschaltet worden:
Änderung WPS/PIN-Methode entfernt
Änderung Veraltete Verschlüsselung WPA/TKIP entfernt
Versuch mal
ssh -4 -p 48612 -l Benutzername xxxxxx.myqnapcloud.comIn post 36 im screenshot sind sowohl Versuche mit IP als auch mit myqnapcloud DNS.
Du hast recht, hatte ich übersehen.
Um weiter helfen zu können, müsste ich an deinem Rechner versuchen, woran es hakt. Ideen wären ssh explizit mit Parameter -6. Ist auf dem lokalen NAS die QFirewall aktiv? Kommst du vom lokalen NAS überhaupt ins Internet (geht sudo ping 9.9.9.9)? Macht Putty irgendetwas anders als ssh (ich kenne Putty nicht)?
Du kannst die Freigaben in /etc/fstab aufnehmen, dann werden sie beim Systemstart automatisch eingebunden, so keine noauto-Option angegeben ist.
Wenn die Freigabe erst beim Login eingebunden werden soll, dann nimmst du stattdessen einen mount-Befehl in die .profile-Datei des Benutzers auf.
Bei Putty nimmst du einen anderen Weg, da gehst du über MyQnapCloud,
Versuch auf dem lokalen NAS einmal
ssh benutzer@Wxxxxx.mqnapcloud.com -p nnnnn -L 38899:localhost:8899(also halt mit der Adresse, die auch in Putty steht).
Geht es dann?
Der direkte Weg, also ohne MyQnapCloud, auf dein fernes NAS, hat vermutlich noch überhaupt nicht funktioniert. Das kann daran liegen, dass der ferne Internetprovider etwas blockiert, dass es an IPv6 liegt oder dass du etwas falsch machst. Mit der Verbindung an ein fernes NAS über IPv6 habe ich noch keine Erfahrung.
Aber mit Putty kannst du dich per ssh mit dem fernen NAS verbinden?
Wie sind denn da deine Aufrufparameter?
(Du hast mit der IPv6-Anbindung und dem Vodafone-Router zwei Komponenten, die ich nicht habe, weswegen ich das hier nicht nachstellen oder verifizieren kann.)
Sieht für mich so aus, dass es geklappt hat.
Ja, das hat geklappt.
Nur nutzt es dir nichts.
An dieser Stelle endet die Analogie des Tunnels. Bei einem Straßentunnel kannst du in beide Richtungen gleichermaßen ein- und ausfahren, beim ssh-Tunnel nicht. Beim ssh-Tunnel können Anfragen nur auf der Seite reingehen, die den Tunnel aufgebaut hat, und in der anderen Richtung können nur Antworten auf genau diese Anfragen geschickt werden. Die andere Seite kann nicht von sich aus neue Anfragen durch den Tunnel schicken, aber genau dies hast du versucht.
Wenn du wie jetzt den Tunnel vom fernen NAS auf das lokale NAS aufbaust, dann muss der RTRR-Client auf den fernen NAS und der RTRR-Server auf dem lokalen NAS laufen, und damit kannst du dann Backups vom fernen NAS auf das lokale NAS machen. Da du dies gar nicht vorhast, da die falsche Richtung, brauchst du keine Energie mehr in die Fehlersuche zu stecken.
Also zurück auf Start.
Du musst mit Putty auf das lokale NAS und dort den Tunnel zum fernen NAS aufbauen.
Da das nicht funktioniert hat, zur Fehlersuche. Funktioniert ssh benutzer@Adresse_fernes_LAN (also Parameter für den Tunnel weggelassen)?
Wenn nein, funktioniert es, wenn du statt den Namens die numerische IP (IPv4 oder IPv6) angibst?
Bestimmt sollte man in der Zeit nicht mit dem Teil arbeiten - oder?
Doch, sicher kann man damit weiter arbeiten. Das ist gerade der Sinn des Raid. Das Raid ist in der Zeit zwar degradiert aber voll einsatzbereit. Schlecht ist nur, wenn in der Zeit eine zweite Platte die Grätsche macht, aber die Last, die dazu führen konnte, kommt durch den Neuaufbau (Rebuild) des Raid, nicht durch die zusätzliche Last, wenn man es benutzt, denn Letzteres ist demgegenüber vernachlässigbar.
In Firmen werden Raids gerne genommen, weil durch den Plattentausch die Produktion nicht gestört wird. Die Mitarbeiter bemerken den Tausch und den Rebuilt nicht.
Das einzige, was man dann keinesfalls machen darf, ist, noch eine Platte ziehen.
Sollte ich den Vorgang beobachten?
Du nimmst eine Tüte Chips oder Popkorn, ein Bier und einen Klappstuhl und setzt dich 36 Stunden vor das NAS und schaust zu. 
Ich kenne spannendere Filme.
Nein, brauchst du nicht zu beobachten. Wenn etwas schief geht, kannst du nicht eingreifen, und dann ist es auch egal, ob du es sofort oder einen Tag später siehst.
Du solltest nur kontrollieren, ob der Rebuild irgendwann durch ist. Da genügt aber, einmal alle ein, zwei Tage nachzuschauen.
Das wäre ein Grund.
Bisher hatte ich schon 40 Jahre Glück
Du hast wohl noch nicht versucht, mit rm -rf .* alle versteckten Dateien und Verzeichnisse zu löschen.
Ich schon.
Ääähm ja.
(Hinweis: Keinesfalls ausprobieren. Das Resultat ist nicht wie erwartet. Stattdessen einmal ls -lR .* eingeben und ansehen, was sonst gelöscht würde. Nur bei bash ab 5.2 tritt der Effekt nicht mehr auf.)
Auch in der Shell gilt es als Sicherheitsempfehlung, nicht mit root/admin zu arbeiten. Gründe dafür sind z. B. :
Ich gebe zu, es kommt vor, dass ich nicht mit einzelnen sudo vor den Befehlen, sondern in einer mit sudo -i erzeugten Shell arbeite, wo ich den Sicherheitsgewinn umgehe, idR dann, wenn ich mich um Backups kümmere. Die Dateinamensvervollständigung funktioniert nämlich nicht bei einem sudo vor dem Befehl, wohl aber in der Shell mit Root-Recht.
Muss ich nun auf dem Lokalen oder auf dem entfernten NAS den RTRR Server starten?
Wenn ich dich richtig verstanden habe, dann willst du vom lokalen NAS auf das entfernte NAS sichern.
In dem Fall musst du nur auf dem entfernten NAS den RTRR-Server starten.
Muss ich die 38899 sowohl bei Server als auch beim Client als Port angeben oder nur bei einem von beiden?
Du hast einen Tunnel, der nicht nur von einem NAS zu einem anderen geht, sondern auch von einem Port zu einem anderen. Auf dem lokalen NAS gehen die Daten in Port 38899 rein und kommen auf dem fernen NAS aus Port 8899 raus, und die Antworten gehen auf dem fernen NAS in Port 8899 rein und kommen auf dem lokalen NAS auf Port 38899 raus.
Also nimmst du auf dem lokalen NAS (das ist der Client) immer den Port 38899, auf dem fernen NAS (das ist der Server) immer den Port 8899, auch wenn es sich um dieselbe Verbindung handelt.
"IP-Adresse/Hostname" localhost >> das kann ich nur beim Client eintragen, korrekt?
Als IP-Adresse/Hostname nimmst du in beiden Fällen nicht die tatsächliche Adresse des Gegenübers, sondern den Eingang des ssh-Tunnels, und der ist jeweils auf dem Gerät selbst, also localhost auf Client wie auch auf Server. Da man aber, so ich das recht in Erinnerung habe, auf dem Server keine Adresse des Gegenübers braucht, es ihm also egal ist, von woher die Daten kommen, musst du im Endeffekt doch nur auf dem Clienten localhost eintragen.
passiert immer wieder das einige Kommandos nicht via sudo oder anderen Nutzern als UID:0 ausgeführt werden können
Für einzelne Kommandos habe ich das nie erlebt, allenfalls für Kommando-Ketten (Kommandos mit pipe verbunden o. Ä.). Aber auch das ist kein Grund, den Admin zu reaktivieren, denn mit
sudo -ierhält man jederzeit eine vollwertige Root-Shell.
Das letzte Mal, wo ich den Default-Admin brauchte, war vor drei Jahren, als ich an der ssh-Konfiguration herumgebastelt und diese zerschossen hatte und mich dann mit Telnet einloggen musste. Das kann tatsächlich nur der echte Admin.
OK, das wäre die nächstliegende Fehlermöglichkeit gewesen.
Üblicherweise kommt der Updatemechanismus mit Benutzereinträgen in /etc/config/crontab gut klar.
Wie hast du die Crontab geändert, mit crontab -e oder mit vi /etc/config/crontab? Wenn ersteres, dann ist normal, dass die Einträge nach einem Reboot weg sind, siehe Doku, und dann hätte das nichts mit der neuen Version zu tun.
Damit wir nicht raten müssen,
Mach In beiden Fällen die externe Adresse unkenntlich, aber lass die interne Adresse stehen.
Zu dem Passwort-Problem: Sagt er wirklich, Passwort falsch, oder sagt er "User/Passwort" falsch? Letzteres kann auch vorkommen, wenn der Benutzer existiert aber sich nicht per ssh anmelden darf.
Kann es daran liegen, dass das entfernte NAS nach außen nur eine IPv6 Adresse hat?
Das geht auch mit IPv6, und die Syntax des ssh-Befehls ist dieselbe. Du brauchst in der Fritzbox dann natürlich eine IPv6-Freigabe. Für IPv6 kannst du keinen alternativen Port wählen, sondern der Port ist zwingend 22 (was bei IPv6 nicht zu dem Problem erhöhter Angriffsversuche führt, wie man es bei v4 hat, s. o.). Damit ist nnnnn aus dem ssh-Befehl dann 22.
Ich synchronisiere zwischen einem Qnap TS-877 und einem Synology NAS. Da gibt es ohnehin kein RTRR, da man dafür zwei Qnap bräuchte, und Rsync hat auf Anhieb inklusive ssh-Tunnel funktioniert. RTRR hat wohl eine Verschlüsselung eingebaut, zumindest wenn mann "SSL" ankreuzt, aber da RTRR wohl schon mal der Einfallspunkt für eine üble Schadsoftware war, gebe ich keine Empfehlung für Qnaps Selbstbaulösung ab.
Wenn du es nicht schaffst, über HBS direkt, d. h. mit Einstellungen in HBS, den ssh-Tunnel zu nutzen, gibt es noch Plan B, den ssh-Tunnel manuell aufzubauen.
Für RTRR über ssh-Tunnel Plan B: Dazu gibst du auf dem lokalen NAS in der Shell ein
ssh benutzer@Adresse_fernes_LAN -p nnnnn -L 38899:localhost:8899Dabei ist nnnnn der Port, den du in der fernen Fritzbox auf Port 22 deines fernen NAS weitergeleitet hast.
In HBS auf dem lokalen NAS legst du dann einen einen RTRR-Server an, nimmst als "IP-Adresse/Hostname" localhost, als Port 38899 und schaltest "SSL" nicht ein (die Verschlüsselung erfolgt ja schon über den Tunnel).
Nachteil davon ist erst einmal, dass so ein ssh-Tunnel gerne zusammenbricht und dass er nicht automatisch geöffnet wird. Die Nachteile kann man beseitigen, aber das gehen wir erst an, wenn die Lösung prinzipiell funktioniert.
Plan B ist allerdings keine Out-of-the-Box-Lösung mehr.
Falls kein Backup vorhanden ist:
Alte Platte wieder rein an Stelle der neuen. Wenn du Glück hast, kann man die Daten dann zumindest wieder lesen, so dass du umgehend ein Backup erstellen kannst (wichtige Daten zuerst kopieren, falls die problematische Platte irgendwann die Grätsche macht).
Ansonsten hilft nur noch ein professioneller Datenrettungsdienst. Das wird allerdings teuer.