Firmware 3.8.4 für TS669Pro gesucht

Mod: Zitat ohne Quellenangabe ... korrigiert! Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen

Zitat von FSC830

Ich komme erst in einigen Wochen dazu, ich brauche noch Zeit um das vorzubereiten.

Ja, ich schrieb ja, wird bei mir sicher erst Ostern werden. Ich wollte nur rechtzeitig alles bereit haben, nicht daß ich anfange und dann irgendetwas fehlt. Aber ich geb auf jeden Fall Info, ob und wie es geklappt hat.

LG

So, ich hab nun aus meinem Q902 ein TS 669 Pro gemacht. Es ging völlig reibungslos und einfacher, als ich dachte. Es ging alles mittels SSH und dem Finder, mehr braucht es nicht, keinen externen Monitor, keine Tastatur, keinen USB-Stick! Kein Datenverlust, kein Neuaufbau des RAID. Ich will es mal ausführlich beschreiben, so daß es jeder nachmachen kann. Es ist viel einfacher, als oft beschrieben.

Voraussetzung: auf dem Q902 ist die letzte verfügbare FW von Fujitsu, die "Q902_20190423-4.3.4-0931.img", das NAS läuft im Netzwerk, man hat SSH-Zugang und kann mit SSH-Befehlen etwas anfangen. Den Laufwerksbezeichner (hier /dev/sdg) und den Arbeitsordner (hier /share/Daten) den tatsächlichen Gegebenheiten des eigenen NAS anpassen.

Der Reihe nach:

1. Laufwerksbezeichner mit fdisk -l ermittelt (hier sdg) und das Fujitsu-System aus dem DOM gesichert

dd if=/dev/sdg of=/share/Daten/Q902_backup.img

und an sicherem Ort außerhalb des NAS gesichert. Das ist der Rettungsanker zurück, falls etwas schief geht.

Konfiguration per Web-IF gesichert

2. Alle Daten auf externe HDDs gesichert

3. Full-Image "Fullrecovery_TS-669_20140516-1.2.8.img" der Einfachheit halber im dom.img umbenannt (muß man aber nicht) und in

/share/Daten auf das NAS kopiert

4. Fullimage in DOM-Flash-Speicher geschrieben

dd if=/share/Daten/dom.img of=/dev/sdg

5. NAS heruntergefahren

6. Festplatten herausgenommen, NAS neu gebootet

7. Nach Hochfahren des NAS mit dem Finder das NAS gesucht und Firmware-Update auf die vorletzte Version (!) gemacht. Das ist die "TS-669_20210413-4.3.4.1652.img"

Der Grund ist der, daß später auf den Platten noch die Fujitsu-FW-Version hinterlegt ist, die mit der aktuellen von QNAP nicht übereinstimmt und ich mir das Neueinrichten und Rücksicherung von terrabyteweise Daten sparen will.

8. Reboot

9. NAS herunterfahren, Platten alle rein, neu starten

10. NAS fährt neu hoch, im Web-IF meckert er erwartungsgemäß, daß auf den HDDs eine andere FW-Version als im Flash ist.

11. per Finder die aktuelle FW flashen (TS-669_20220303-4.3.4.1976). Das ist der Grund, warum ich zunächst eine Version älter geflasht hatte! Danach paßt wieder alles.

12. Reboot

13. optional Browsercache auf dem Rechner löschen, um letzte Rester der Fujitsu-FW, die aus dem Cache geladen werden, zu entfernen (bei mir z.B. das Favicon)

Das Q902 meldet sich nun als TS 669 Pro, aktuelle QNAP-FW-Version ist drauf und hat (ohne Backup und Firmwarebeschaffung) ca. eine halbe Stunde gedauert.

Schritt 1 und 2 sind der Rettungsanker, wenn etwas schief geht. Wer keine Daten auf dem Gerät hat oder aktuelle Backups, kann zumindest Schritt 2 sparen.

Das Q902 ist nun ein vollwertiges TS669 Pro inkl. HDMI-Port. Einzig das BIOS meldet sich noch mit dem Fujitsu-Logo, da müßte man noch ein BIOS-Update auf QNAP-Original machen. Aber das BIOS wird es wohl nicht geben und ob es ein Update-Prog wie beim PC gibt oder ob das nur per RS232 geht, weiß ich nicht.

Zitat von FSC830

Auch wenn sofort die 4.3.4.1976 geflasht wird, beim Boot mit den Platten und der nicht übereinstimmenden FW kann man die .1976 doch auch erneut flashen?

Das weiß ich nicht, ob er das macht oder ob er das verweigert bzw. nicht flasht, weil die identische Version im DOM-Flash schon drauf ist und nur auf den Platten nicht. Ich bin da vorsichtig und wollte es einfach nicht drauf ankommen lassen.

So, ich habe mir nun gestern den halben Tag "verspielt", um einen Konfigurationsfehler zu finden, der gar nicht da war.

Nachdem ich über Nacht sowohl NAS als auch Rechner heruntergefahren hatte, ging morgens der Samba-Zugriff auf Gast-Ebene nicht mehr wie gewohnt. Obwohl im Web-IF der Gastzugang aktiviert ist, wollte das NAS immer Benutzername/Paßwort. Ich habe ewig nach dem Fehler gesucht, die smb.conf überprüft und testweise verändert, nichts. Ich hab dann die 6 Platten herausgenommen und ein Testsystem mit einer Platte installiert und komplett jungfräulich neu aufgesetzt. Dachte, vielleicht beißt sich meine Q-902-Konfig mit der aktuellen TS-669-Firmware. Nichts. Keine Chance. Weder mit Windows-Rechnern noch mit Android ging der Gastzugang ohne Passwort.

Ich hab dann die Firmware auf in etwa den FW-Stand des Q902 downgegradet und siehe da, plötzlich ging der Gastzugang einwandfrei. Firmwarestände Stück für Stück hochgefahren und es ist eindeutig ein Bug (QNAP nennt es aber natürlich Feature oder Security-Patch) in der Firmware.

Bis "TS-669_20190322-4.3.4.0899" geht der Gastzugang über Samba einwandfrei, ab "TS-669_20190730-4.3.4.1029" funktioniert er nicht mehr. Steht bei genaurem Hinsehen auch im Changelog aber auf so eine Idee muß man ersteinmal kommen, daß eine Sache im Web-IF und in der smb.conf aktivierbar ist und dann doch nicht funktioniert.

Über Sinn und Unsinn eines Gastzuganges will ich nicht diskutieren oder streiten, da steht genügend im Forum aber es sollte doch jedem selbst überlassen sein, ob er an einem NAS, was hinter einer Firewall und nicht im Internet hängt, bestimmte Ordner für jedermann freigibt oder nicht. Gerade das ist ja der Vorteil von Linux-Systemen und Samba, daß man es frei konfigurieren kann. Daß man das für DAUs per Default ersteinmal ausschaltet, ist verständlich und gut, aber es von einem FW-Stand zum anderen komplett zu deaktivieren, obwohl man es im Web-IF und der smb.conf aktivieren kann, ist schon ne Nummer.

Zum Glück läßt sich auch das lösen mit einer kleinen Änderung in der smb.conf und der smb.sh, hier der Workaround, ich hoffe, der Link ist gestattet: https://forum.qnap.com/viewtopic.php?f=185&t=149124&start=15

Also wer vorhat das Q902 zu einem TS669Pro zu machen, bitte beachten, bei aktueller FW sind die Guest-Shares bei Samba weg.

Was mir noch aufgefallen ist und mich "nur" eine halbe Stunde Fehlersuche gekostet hat und absolut kurios ist, ist die Bindung des Web-IF von Twonky-Server (hier Version 8.3.1) an einen bestimmten LAN-Port:

ich habe das NAS an 2 LAN-Ports angeschlossen ohne Servicebindung. IPs statisch festgelegt, einmal die xxx.16 und einmal die xxx.17. Die Konfiguration mach ich per xxx.16. Bei der alten FW vom Q902 hab ich auf das QTwonky-App-Symbol auf dem Desktop geklickt und konnte den Twonky konfigurieren (xxx.16:9000). Das ging plötzlich nicht mehr, Seite nicht gefunden, obwohl Twonky problemos lief. Nur das Web-IF war weg. Nach zig Neustarts und Neuinstallation von QTwonky kam mir dann die Idee, es mal händisch mit der anderen IP, der xxx.17 zu versuchen und tatsächlich, das Web-IF von Twonky ist dorthin gewandert, egal, ob ich das Web-IF des NAS mit der xxx.16 oder xxx.17 aufgerufen hab. Sobald ich das Kabel von LAN2 herausziehe, ist das Web-IF von QTwonky wieder über xxx.16:9000 erreichbar.

Das war mit der alten FW nicht so. Das ist jetzt kein Beinbruch, aber man muß es wissen, kommt man ja nicht gleich drauf, daß das Web-IF von Twonky immer nur über einen (den höheren?) LAN-Port erreichbar ist und nicht wie das Web-IF vom NAS über beide.

Das nochmal als Ergänzung und Hinweis für diejenigen, die das gleiche vor haben.

Wenn ich mit allem durch bin, werde ich mal den Hinweis befolgen und eine kleine Anleitung im Blog schreiben.

Also ich hab einen Unmanaged Switch HP ProCurve 1410-16G dranhängen, der kann IMHO kein Link Aggregation, weshalb es am NAS nicht eingerichtet ist. Ich brauch das auch nicht und werde deshalb nicht den Switch ersetzen. Die beiden LAN-Anschlüsse sind deshalb konfiguriert und gesteckt, weil ich mal vorhatte/habe über einen den Netzwerkverkehr zu machen, über den anderen ein Backup übers Netz. Aber Sinn und Unsinn dieser Konfiguration ist auch gar nicht Thema des Beitrages und Offtoppic.

Was aber wieder dazwischenfunkt und damit zurück zum Toppic ist folgendes:

Nach Neustart ist die smb.sh wieder durch die originale der FW ersetzt, d.h. meine Änderungen sind wieder weg.

Weiß jemand, wo das konfiguriert ist, daß die smb.sh zurückgesetzt wird, entweder durch eine Default-Version oder direkt aus dem Flash? Als Workaround könnte ich natürlich ein Start-Script schreiben, was bei jedem Neustart diese Datei gegen meine ersetzt oder versuchen, diese mit CHMOD auf schreibgeschützt zu setzen.

Aber das fällt alles in den Bereich "Krücke", sauber ist was anderes.

Edit: CHMOD auf 555 bringt schonmal nichts, nach Neustart ist wieder die Originaldatei da mit 0755.