Beiträge von subitus

Gratulation und viel Spaß beim Virtualisieren.

Gruß vom subitus

Wenn du mit Performance meinst, ob man flüssig arbeiten kann: ja, das geht.
Wenn du die restliche NAS-Performance ansprichst: ich lasse i.d.R. ein Linux-OS permanent laufen (CPU-Limit und 1 Core) mit 1GB RAM sowie i.d.R. Win7 mit 2 Cores und 8GB RAM nach Bedarf.
Ansonsten laufen noch einige Docker in der Container Station permanent.

Hi paini,

auch wenn es dir nicht unmittelbar hilft: ich werde kein NAS mehr mit externem Netzteil kaufen, da mit der Zeit Probleme am Poweranschluss auftraten, ein Gerät ging mehrfach retoure, bei einem dritten traten nach 2.5Jahren Probleme auf und ich musste den Lötkolben schwingen und die Buchse tauschen (TS119P+).

Ich habe vor kurzem eine TS563 gekauft, gerade auch wegen der Möglichkeit zu virtualisieren. Die vorhandenen VMware und VirtualBox-Images laufen jetzt auf dem NAS und jeder kann von jedem Ort mit jedem Gerät auf die Virtualisierungen zugreifen.

Nur so am Rande, wenn du sowieso dabei bist, Geld auszugeben

Gruß vom subitus

Hallo und ein gut's Neues!

Ich habe das Problem mit der sich verstellenden MAC-Adresse nach einem FW-Update auch und seither im Autostart-Skript

/sbin/set_mac <MAC-Adresse>

stehen.

Interessieren würde mich aber, warum ein FW-Update überhaupt die MAC-Adresse verändert? Kann jemand einen sachdienlichen Hinweis geben?

Gruß vom subitus

Ich kann nur bekräftigen, SVN als eigenständigen Dienst (svnserve) zu installieren.

Gruß vom subitus

Hallo Thomas,

ich kann bestätigen, dass sich bei einem meiner QNAP-NAS mit QTS 4+ die MAC-Adresse geändert haben muss. Dies fiel mir irgendwann in der Verbindungsliste des Routers auf, weil das NAS einmal mit der alten und mit der neuen MAC-Adresse aufgeführt wurde und die neue MAC-Adresse auffällig viele Nullen enthielt. Darauf gestoßen bin ich erst, als meine WOL-App auf dem Smartphone nicht mehr funktionierte.

Irgendwelche Erklärungen hierfür?

Gruß vom subitus

Wenn es weiterhilft: Bei mir läuft SVN als eigenständiger Dienst (svnserve) und nicht als Apache-Modul.

BTW: Das Apachemodul hätte jedoch den Vorteil, dass die Autorisation durch die Windows-Domäne mittels SSPI erfolgen kann.

Gruß vom subitus

LordOfTheSnow,

nein, das NAS mus nicht zwingend eine feste IP besitzen, um die E-Mail-Funktion nutzen zu können, wenngleich eine statische IP bei festen Netzwerkinfrastrukturen zu empfehlen ist. Aus meiner Sicht spricht nichts dafür, dass das NAS mittels DHCP betrieben werden müsste.

Ohne statische IP kann man das NAS und dessen Dienste problemlos über den Gerätenamen bzw. den Domänenbezeichner ansprechen (die fritz.box listet diesen in der Geräteliste auf).

mc.camper,

hast du ausprobiert, ob Web.de-SMTP über TLS am Port 587 funktioniert?

Gruß vom subitus

Der Wunsch ist obsolet, da bereits seit einiger Zeit implementiert. Hat's was gebracht

Hast du denn die Erweiterungen installiert?

Bspw. mit:

pear install XML_Feed_Parser

usw.

Und hast du die Zugriffsrechte, die bemängelt werden, gesetzt?

Gruß vom subitus

Hallo,

wenn du uns mitteilst, wie du die Synchronisation genau durchführst, können wir dir vielleicht weiterhelfen. Gründe kann es viele geben. Bspw. könnte das W-Lan ein Flaschenhals sein - da können die Festplatten noch so schnell sein...

Gruß vom subitus

Die erstmalige Synchronisation dauert immer sehr lange - abhängig von der Anzahl der Dateien und deren Größe. Die wiederkehrende Synchronisation geht schneller vonstatten - kann aber durchaus auch etwas dauern (wenn die Verbindung lahm ist und viele Dateien zu vergleichen sind). 600 GB ist kein Pappenstil.

Poste bitte mal deine Erfahrungen nach einigen Wochen. Interessant wäre noch: Wieviele Dateien werden synchronisiert?

Grüße vom subitus

Korrekt!

Schematisch sieht das so aus:
Internet (WAN-IP:WAN-Port) => Router (Übersetzt WAN-IP und WAN-Port in LAN-IP und LAN-Port) => LAN (QNAP LAN-IP:LAN-Port)

Der WAN-Port im Router ist zusammen mit der WAN-IP jene Adresse, mit dem der RTRR-Service aus dem Internet erreichbar ist.

Man könnte die WAN-Portadresse gleich dem RTRR-Port des QNAP setzen, wenn innerhalb des lokalen Netzwerkes nur ein RTRR-Dienst läuft.

Gruß vom subitus

So schnell werde ich mir QTS4.1 nicht antuen... wenn du warten kannst

Andernfalls mal das Dateisystem nach alarm, rtc, wakeup etc. absuchen...
...irgendwo muss die Schnittstelle im Userland sein.

Gruß vom subitus

Hallo alexi,

den WAN-Port bestimmst du selber und konfigurierst den Router entsprechend. Darüber hinaus kann auch der LAN-Port frei bestimmt und im QNAP-Admin-Panel konfiguriert werden.

Gruß vom subitus

ERASER:
Nachvollzogen habe ich es auf einer ARM-Kiste mit QTS 4.07. Auf den Intel-NAS mit v3.8 klappt dies identisch.

Welche Firmware/ Kernelversion benutzt du?

Gruß vom subitus

Zitat von "Eraser-EMC2-"

subitus
Welches NAS besitzt du , ein NAS mit ARM- oder x86-CPU ?

Beides - siehe Signatur.

Zitat von "Schmidder"

Ist wohl ein Fall für den Support.

Hmmm... das sieht wohl leider danach aus. Wende dich am besten direkt an den Technical Support Taiwan mit ausführlicher Dokumentation. Vlt. kann dir geholfen werden.

Gruß vom subitus

Hallo Schmidder,

zunächst: Meine ARM(e)-Kiste unterstützt nach einem Stromausfall auch keinen Zeitplan und kein WoL. Dies fällt bei mir aber nicht ins Gewicht, weil ich alle NAS an USV's betreibe. Meine Intel-NAS lassen sich von einem Stromausfall nicht sonderlich beeindrucken und funktionieren erwartungsgemäß.

Grundsätzlich ist dies eine Einschränkung der verwendeten Hardware.

Zurück zum Thema:
Mir fällt auf, dass in deiner Konfiguration kein Shutdown per Zeitplan programmiert ist, sondern nur ein Power-On? Eigentlich sollte das kein Problem sein (wenn beabsichtigt ist, dass das NAS ständig laufen soll). Ich erinnere mich noch vage an ein Power-On-Problem in einem anderen Forum - da war die Lösung auch einen Shutdown per Zeitplan einzustellen. Das klingt zwar unlogisch, denkbar wäre es. Zumindest wäre es ein weiterer, nachweisbarer Fehler. Vielleicht könntest du dies abklären?

Die Schnittstelle /proc/acpi/alarm ist aus Kompatibilitätsgrunden aus alten Kernelversionen vorhanden (ich denke vor 2.6.22). Relevant ist daher die Ausgabe von /proc/driver/rtc Die Datei /etc/config/rtc_last_save enthält beide Ausgaben zum Zeitpunkt eines Shutdowns.

Erklärung: Die Angaben alarm_time und alarm_date liegen in der Vergangenheit - daher sind sie mit *** ausgeblendet.

So wie es aber aussieht, hätte das NAS starten müssen...

Als nächsten Schritt kannst du direkt prüfen, ob die Echtzeituhr funktioniert. Dazu schreibst du mit

echo 2014-04-25 22:00:00 > /proc/acpi/alarm

die Alarmzeit in die Echtzeituhr und überprüfst anschließend mit

cat /proc/driver/rtc

ob die Alarmzeit gesetzt wurde. Wichtig ist, dass der Eintrag alarm_IRQ auf yes steht:

alarm_IRQ   : yes

Bevor das NAS heruntergefahren wird, muss noch eine Kleinigkeit erfolgen:
Da die Shutdown-Skripte die Echtzeituhr überschreiben, musst du dies temporär unterbinden. Öffne die Datei /etc/init.d/shutdown_check.sh, bspw. mit

# joe /etc/init.d/shutdown_check.sh

und kommentiere die Zeile aus:
VORHER:

/sbin/gen_next_alarm 2

NACHER:

# /sbin/gen_next_alarm 2

Anschließend fährst du das System mit

halt

herunter.

Wenn alles klappt, startet die Kiste zur eingestellten Zeit.

Die Datei /etc/init.d/shutdown_check.sh wird mit dem nächsten Start aus dem Flash gelesen und liegt wieder in unveränderter Form vor.

Wenn das NAS nicht startet (bitte alles mit Zeitstempel dokumentieren und für einen Shutdown mind. 5 Minuten einplanen), ist es ein Fall für den technischen Support von QNAP.

Gruß vom subitus

Zitat von "Martin Lemke"

... lokal nun erreichbar unter: http://Klotz.fritz.box... Dies nur als Nebenbemerkung, weil vielleicht nicht allen, die hier lesen, klar ist, dass man die Geräte so ansprechen kann.

Btw.: Innerhalb einer Domäne kann der Domänenname auch weggelassen werden. Ich rufe das NAS daher synonym mit "http://klotz" auf.

Gruß vom subitus

Zitat von "rubinho"

... mache ich mir schon ein wenig sorgen.
Gleiches gilt auch für Owncloud User.]

Btw.: Der Heartbleed-Bug ist bei der Nutzung von Owncloud das geringster aller Probleme...
Die Anzahl der sicherheitskritischen Lücken ist seit Jahren erschreckend hoch, was den unreifen Character dieses Produktes (ja, es ist zu Teilen kommerziell) unterstreicht. Bislang lag der Fokus ohnehin nicht auf Sicherheit, sondern auf das Ergattern von Marktanteilen - bisweilen mit gesponsertem Code für die Community. Da die Informationspolitik des Unternehmens ownCloud Inc. erstaunlich zurückhaltend ist, durfte der Fachwelt damals (2012) spätestens beim Lesen dieses Artikels die Fußnägel hochgerollt sein: http://crypto.junod.info/2012/…cloud-4-0-and-encryption/

Grundsätzliches bezüglich der Sicherheit hat sich seit dem nicht geändert.

Gruß vom subitus