Beiträge von martinelli

Hallo Gemeinde,

seit QTS 4.4.1.1117_B20191109 kann ich am TV keine PNG-Dateien mehr ansehen, die auf meinem TS-453 gespeichert sind. Entweder kommt "Datei nicht gefunden." oder andere Ordner mit png-Files werden als leer dargestellt. Fotos im jpg-Format sind ok. Bei meinem zweiten Qnap (TS-439), ebenfalls mit der aktuellen OS-Version, ist alles ok.

Auch am TS-453 war bis zum letzten Update alles anzeigbar, jpg und auch png (u. a. mehr).

Hat jemand das gleiche Problem, ist dazu schon etwas bekannt? Habe nichts dazu gefunden...

Danke im Voraus für jede erhellende Rückmeldung!

Gruß

martinelli

Hallo Forum,

bei meinem alten Qnap, das noch unter QTS 4.2.6 lief, gab es einen DLNA-Server (Twonky), der fast alle Videoformate wiedergeben konnte, u. a. auch mov-Dateien. Ab der neuen QTS4.3.3-Version (auf einem ebenfalls neuen Qnap) ist der Twonky-Server leider weggefallen und der Medienserver kann keine mov-Dateien abspielen.

Gibt es dafür Abhilfe?

Danke im Voraus für jeden Tipp.

Gruß
martinelli

Gleiches Problem bei einem TS-439 Pro II+... aber noch seltsamer: von 9 NFS-Shares (unter Debian) werden 3 anstandslos gemountet, bei den übrigen 5 gibt es ein "access denied". Alle Einstellungen wiederholt geprüft, sie sind identisch. Eine der fehlerhaften Shares gelöscht, neu hinzugefügt, Fehler bleibt.

Der Versuch, die export-Datei zu bearbeiten (bei mir war es ein Fehler in Zeile 5, den exportfs -a ausgegeben hat), hat auch nichts gebracht, denn die Zeile 5 war genauso - korrekt - geschrieben wie die drei Zeilen der funktionierenden Shares. Überall ein * für alle berechtigten Rechner.

Seltsam, seltsam...

Gruß
martinelli

<42>

--- ModEdit ---

Muss meine Aussage revidieren, manchmal sollte man zweimal hinsehen...

Auch bei mir waren fehlerhafte Einträge in der exports das Problem, denn genau bis zum ersten Fehler wurde alles gemountet:

"/share/MD0_DATA/Q_PIX" 10.193.84.1(rw,async,no_subtree_check,insecure,no_root_squash)10.193.88.7(rw,async,no_subtree_check,insecure,no_root_squash)

Nach dem Ersetzen der ersten IP-Adresse durch * und dem Löschen des hinteren Teils (beginnend mit der zweiten erlaubten IP), war alles es ok.

Und wenn aber auf die Share "Q_PIX" mehrere Adressen erlaubt werden sollen, muss man für jede IP-Adresse einen eigenen Eintrag erzeugen:

"/share/MD0_DATA/Q_PIX" 10.193.84.1(rw,async,no_subtree_check,insecure,no_root_squash)
"/share/MD0_DATA/Q_PIX" 10.193.88.7(rw,async,no_subtree_check,insecure,no_root_squash)

Danach war alles ok, also die gleiche Ursache wie bei filozione. Habe aber noch keinen Neustart versucht, um zu sehen, ob die Einstellungen erhalten bleiben...

Gruß
martinelli

<42>

Hallo Forum,

seit Upgrade auf 3.8.2 kann mein iSCSI-Initiator per gPXE nicht mehr das iSCSI-Target auf dem Qnap (TS439 Pro II +) booten,
"Login Fail" meint das Qnap und im Logging steht unter Users seit 3.8.2 nicht mehr der IQN der Diskless-Station, sondern
"System". CHAP ist und war nicht eingerichtet.

Eine weitere iSCSI-Verbindung (zum ESXi-Server) funzt nach wie vor einwandfrei.

Auch mit der neuesten FW (4.0.2) ist das Problem noch nicht behoben - weiß jemand Abhilfe?

Danke im Voraus!

Hallo Gorilla,

ich weiß zwar nicht, ob das "Wiederbeleben" eines alten - aber noch offenen - Threads funktioniert, ich versuchs einfach...

Gibt es schon etwas Neues zu meinem Problem? Habe heute gerade aktualisiert auf 4.0.2, der Fehler bleibt, mit der
gleichen Meldung auf dem Qnap. "Login failed".

Danke im Voraus.

Du hast auch hier Recht, wobei ich mich ja schon beherrscht habe (meiner Meinung nach) ...;-)

Es ist also vermutlich zwecklos, auf eine Lösung aus der Gemeinde zu hoffen, wenn die 3.8 so buggy ist,
und damit vermutlich auch der Bereich iSCSI betroffen ist?

eieiei.. Man sollte auch wirklich bis zum Ende des Posts lesen...

1:0 für Dich, Gorilla :thumb:

wo immer Du das gesehen haben magst, dass es explizit um diese Zeile geht ...

Aber vielleicht bist Du ja in einem anderen Forum? Oder meine Augen sind kaputt

Hallo Forum,

mit dem Upgrade von 3.8.1 auf 3.8.2 kann mein iSCSI-Initiator per gPXE nicht mehr das iSCSI-Target auf dem Qnap
(TS439 Pro II +) booten, "Login Fail" meint das Qnap und im Logging steht unter Users seit 3.8.2 nicht mehr der IQN
der Diskless-Station, sondern "System". CHAP ist und war nicht eingerichtet.

Offensichtlich hat man bei Qnap schon wieder etwas verpfuscht (diesmal bei iSCSI), denn das fand ich in einem anderen
Post:

"Die FW kann nicht mehr downgegraded werden von 3.8.2, da die iSCSI Einstellungen modifiziert wurden.
Die neue FW kommt binnen in 2 Wochen , QTS 4.0."

Das ist aber nicht das einzige, was Qnap mit einer neuen FW verschlechtert, einen weiteren Punkt kann man hier finden, so
dass man sich unwillkürlich fragt, was die in Taiwan wohl rauchen... http://forum.qnap.com/viewtopic.php?f=151&t=67896#p305160

Hallo q412,

falls der Link, der Dir "angeboten" wurde, nicht funzt - bei mir hat er genau das gleiche Problem auch nicht gelöst, wohl
aber das Folgende.

Dies sind bzw. waren die ersten drei Zeilen meiner smb.conf:

map hidden = no
[global]
passdb backend = smbpasswd

Die erste Zeile ist die, die sämtliche Änderungen via GUI an Shares und Permissions verhindert, dort muss zwingend
die Zeile mit [global] stehen. Zeile gelöscht (nicht auskommentieren, das ändert nichts), alles ok.

Der Tipp, eine Konfig zurückzusichern, hat bei mir auch nicht funktioniert - was auch Zufall wäre, weil man ja nicht sagen
kann, seit wann die smb.conf den Schuss hat; falls Du das gleiche Problem haben soltest...

Viel Glück!

Du hast Recht, habe ich übersehen, bzw. nur am Rande bemerkt und ignoriert, weil ich das bereits - vergeblich - versucht hatte.

Bei mir hat das Folgende geholfen. Dies sind die ersten drei Zeilen meiner smb.conf:

map hidden = no
[global]
passdb backend = smbpasswd

Die erste Zeile ist die, die sämtliche Änderungen via GUI an Shares und Permissions verhindert. Zeile gelöscht, alles ok.

Dank nochmals an schumaku (Switzerland).

Danke für Deine Antwort, leider hilft mir die nur bedingt weiter.

Das Zurücksichern einer alten Konfig lässt meine aktuelle V3.8.2 sicher nicht unangetastet, oder ich müsste die aktuelle FW noch einmal
drüberspielen. Der Hinweis auf das passende Topic - smb.conf editieren - bringt ja auch nicht wirklich etwas, denn dort wird auch nur
spekuliert, dass es die smb.conf sein könnte, ohne Hinweis, was es ist...

Ich sehe sie mir mal an, ob etwas auffällig ist.

Nachtrag:
Das Zurücksichern der ältesten Konfig (Firmwarestand 3.6.2 von Februar 2012) hat nichts geändert, das Problem bleibt.

Man kann der Share nicht einmal lokale User zuweisen oder Full Access einstellen, jede der vorgenommenen Änderungen
lässt sich gar nicht erst speichern oder verschwindet wieder nach dem Speichern.

Wenn es einen - funktionsfähigen - Qnap-Support in Deutschland gäbe, würde der sich vielleicht darum kümmern, der stellt
sich aber lieber tot, denn dann hat man ja weniger zu tun. Wir haben noch ein anderes Problem, dieses per Mail gemeldet und
ein Ticket eröffnet, was aber nicht bedeutet, dass sich Qnap Deutschland auch darum kümmert.

Sehr enttäuschend, Qnap...

Hallo Forum,

wir setzen mehrere Qnap ein, u.a. ein TS-410 als Dritt-Fileserver, FW ist 3.8.2, das Gerät ist im AD. Vor einigen Monaten ließ sich noch ein
Shared Folder, inklusive der AD-User erstellen, Zugriff und alles andere funktionieren seitdem einwandfrei. Eine weitere Freigabe konnten wir
heute erstellen, es lässt sich aber nichts an den Eigenschaften ändern. Weder kann man einen (lokalen) Qnap-User hinzufügen, noch einen
AD-Benutzer.

Nach Hinfzufügen und Apply dauert es immer einige Sekunden, dann verschwindet der eben vorgenommene Eintrag. Auch die Einstellung
"Guest access right" lässt keine Änderung zu und springt nach dem Speichern immer wieder auf "Deny access" zurück.

Warum damals die erste Freigabe und deren 5 AD-User angelegt werden konnte, ist unklar. Geändert wurde seither am Gerät nichts, außer einige
Firmware-Updates. Aber vielleicht war ja das der Fehler...

Übrigens bringt auch das manuelle Editieren der smb.conf nichts, die darin eingetragenen User erscheinen ebenfalls nicht.

Wäre schön, wenn jemand Rat weiß.

Danke im Voraus!

ja, genau der Effekt tritt auf, wenn der Switch zu Ethernet 1 noch nicht aktiv ist. Also offensichtlich eine
Verschlimmbesserung von Qnap, auch wenn die "Gateway-Auto"-Funktion ja ganz nützlich sein kann.

Kann ...

Stimmt, da hast Du Recht...

Die Konfig ist überschaubar: über Ethernet 2 erreicht der ESXi-Server das iSCSI-Target auf dem Qnap, auf dem die Virtuellen Maschinen liegen.
Ethernet 1 bedient den Rest, ist also die Verbindung zu den Shares, zum Qnap-Management, nach extern, usw.; kein Port Trunking.

Weniger wichtig aber kein Geheimnis sind die übrigen Einstellungen:

Ethernet 1: 1000 Full Duplex / MTU 9000
Ethernet 2: Auto-negotiation / MTU 1500 / kein Gatewayeintrag (logisch...)

Hallo Forum,

bis zur Version 3.8.0 war bei meinem TS439 Pro II+ alles ok. Seit dem Upgrade auf 3.8.1 (und seit Sonntag auch mit 3.8.2) geht die Einstellung
für das Standard-Gateway immer wieder verloren. Ich stelle Ethernet1 ein und beim Versuch, von extern auf das Qnap zuzugreifen schlägt dieser
regelmäßig fehl, denn in der Konfig steht immer wieder Ethernet2 drin.

Das Qnap wird nie abgeschaltet, nur die HDDs werden nach 30 Minuten - wenn der ESX-Server nicht mehr auf das Qnap zugreift - angehalten,
es gibt also keinen Reboot, der die Konfig durcheinander bringen könnte.

Weiß jemand Rat?

Hallo,

die vielen Meinungen dazu, die immer die gleichen zwei Möglichkeiten zulassen, kenne ich auch,
konnte mich aber bis heute nicht entscheiden. Wobei man 4 Platten, egal welche Größe sie haben,
nach 3 Jahren wirklich einfach ersetzen kann und sollte, denn bis dahin spielen "Abschalten oder nicht",
oder lieber Dauerlauf kaum eine Rolle.

Ich denke aber, Du hast Recht, ein gesundes Mittelmaß machts, wie im übrigen Leben auch...

Hallo zusammen,

für die o.g. Frage brauche ich die Hilfe des Forums. Zwar habe ich 24x7-Festplatten in meinem Qnap eingebaut,
möchte aber trotzdem in der Nacht die HDDs bei Nichtaktivität abschalten lassen.

Was ist für die Lebensdauer der Platten besser, der permanente Betrieb oder ein regelmäßiges Abschalten,
aber verbunden mit einer geringeren Betriebsdauer?

Danke im Voraus für eure "Entscheidungshilfe"...

Hi,

habe ich gerade erfolgreich hinter mich gebracht (TS-410 nach TS439 Pro II +), ebenfalls mit 4x HDD im Raid 5. HDDs ins neue Qnap
einbauen (Reihenfolge beachten, logo ... und vorsichtshalber noch ein Backup ziehen). Neues Qnap einschalten, warten bis die bestehende
Konfig von den Platten gezogen wurde, fertig!

Dummerweise hatte ich vorher nicht die Firmware angepasst, so dass das neue die aktuelle Version angezeigt hat, tatsächlich war es
aber eine Version zurück. Die aktuelle erneut installiert, dann war es wirklich ok. Aber das trifft ja bei Dir nicht zu.

Viel Glück!

Hallo Micha,

das Problem ist gelöst. Nachdem ich erfahren habe, dass die fehlenden Punkte genau den Änderungen in Firmware 3.5.1 entsprechen,
habe ich diese Version aufgespielt und damit war alles ok. Die Anzeige der vermeintlich aktuellen Firmware hat sich das Qnap aus der
Konfig auf den bestehenden Platten geholt. Diese musste ich anfangs nur ins 439 einbauen und hochfahren, womit ich den alten Stand hatte.

Wenn auch mit einer falschen Firmware-Anzeige...

Trotzdem danke für den Tipp.