Beiträge von tjareson

Da bin ich auch gerade drüber gestolpert. Ist dann aber echte 2 Wege Sync und ich müsste dann tatsächlich die lokale Sync nochmal lokal kopieren. Das ist irgendwie Platzverschwendung.

Betreffend FTP: wenn ich das richtig sehe, ist es ja keine Protokollfrage. Auch ftp ist aus QNAP-Perspektive ja nur Backup-Ziel, aber keine Quelle?

Kennt jemand vielleicht irgendeine QNAP-app, in der man ein paar bash-Anweisungen als batch ausführen lassen kann? Ich weigere mich momentan noch irgendwie, das im CLI zu lösen - das sind ja immer so Konfigurationen, die man dann irgendwann einfach vergisst. Deswegen wäre mir eine App-Variante deutlich lieber.

Nextcloud lässt sich auf "User-Ebene" ohne weiteres per webdav in QNAP einbinden. Einfach mit HybridMount einbinden. (bin mir gerade nicht sicher, welche QTS-Version man dafür mindestens braucht)

Dann kann man mit File-Station in QNAP vom Remote-Nextcloud-User nach lokal kopieren. Der Vorgang ist dort allerdings manuell. Ich suche aktuell selber noch nach einer komfortablen Möglichkeit Backup webdav->lokal zu machen. Hybrid-Cloud kann das immer noch nicht, was für mich völlig unverständlich ist.

Das webdav->lokal Problem wurde auch hier schon mal diskutiert (ohne nextcloud, aber auf was man mit webdav zugreift ist an sich ja egal)

Wöchentliches Backup eines WebDAV auf dem QNAP - Schwerer als gedacht...

Ich könnte natürlich irgendeine bash Lösung mit cron basteln, aber eigentlich kann das ja nicht sein...

Hallo,

der Beitrag ist zwar schon etwas älter - aber hat sich hier eigentlich irgendetwas getan?

Ich habe genau die gleiche Anforderung, ich möchte Verzeichnisse, die per webdav erreichbar sind lokal auf QNAP sichern.

Sitze hier mit QTS5 und Hybrid Backup und immer noch das gleiche Problem. Technisch ist ja alles da, nur die Richtung der Kopie ist nicht einstellbar.

Und nein, ich will die Sicherung nicht von der Quelle aus machen, alleine schon deshalb, damit bei einem Hack des Quellserver das Backup-System weder sichtbar, noch irgendwie erreichbar ist.

Hallo zusammen,

ich habe hier eine Problemstellung, bei der in nicht ganz sicher bin, ob's hierher gehört.

Für eine C-basierte Anwendung für die Konfiguration von Zugangssystemen, die unter Linux im Textmodus läuft, musste ich ncurses 5.9 auf meinem QNAP installieren. (Zugriff erfolgt dann über separat installierten SSH-Zugang, damit auch login als non-admin funktioniert)

Das Problem ist, dass die Installation von ncurses bei jedem Neustart vom QNAP weg ist. Ich bin ehrlich gesagt betreffend QNAP nicht weit genug im Detail, als das ich wüsste, wie ncurses installiert werden muss, damit es auch einen Neustart überlebt.
Da mein QNAP nur 1-2 mal im Jahr überhaupt neu gestartet wird, hatte ich an einen Workaround gedacht, der das "make install" im ncurses-Verzeichnis beim QNAP-Start einfach nochmal durchführt.
(eingerichtet gemäß Method 3 in http://wiki.qnap.com/wiki/Runn…wn_Application_at_Startup )
Es wird auch alles in der autostart.sh ausgeführt, nur das make install von ncurses klappt einfach nicht. Führe ich den gleichen Befehl in der autostart.sh in der ssh-Konsole von QNAP aus, dann ist ncureses installiert (und die oben erwähnte C-Anwendung läuft).

Hat jemand eine Idee, in welche Richtung es sich lohnt zu suchen? Ich hatte schon daran gedacht, ob ggf. noch nicht alle Pfade konfiguriert sind etc. und versucht, dem mit absoluten, vollständigen Pfadangaben vorzubeugen, aber bislang ohne Erfolg. Mir ist auch nicht ganz klar, zu welchem Zeitpunkt genau die autorun.sh ausgeführt und ob deren Ergebnisse ggf. im Laufe des Systemstarts bspw. wieder überschrieben werden usw. Das Problem ist, das ich mit jedem Test das QNAP neu starten muss, was relativ mühselig ist. Am besten wäre es natürlich, ncurses dauerhaft installiert zu bekommen.

Beste Grüße.
Tjareson

Also ich habe es jetzt so "halbgar" hinbekommen, in dem ich für das entsprechende Share auf dem QNAP einfach Guest-User zugelassen habe (read&write) und den vorherigen User-Account mit dem sich der MS-Client von DOS aus anmelden soll auf dem QNAP wieder gelöscht habe. Damit erfolgt der Zugriff auf das Verzeichnis als anonymer User (eben Guest) und es wird keine Passwortabfrage seitens SAMBA gemacht. Den Zugriff habe ich dann auf dem QNAP wiederum auf die IP-Adresse des DOS-Rechners eingeschränkt. Nicht besonders sicher, aber damit funktioniert es zumindest erstmal. (Kleiner Nebeneffekt ist, dass sich damit dann auch Drucker am QNAP per net use als normales lpt-device unter DOS nutzen lassen...

Beste Grüße
Tjareson

Auch wenn off-topic: Wenn der Rechner, auf dem VMWare läuft, kein 3,5"-Laufwerk mehr hat, nützt uns Virtualisieren gar nichts. Die Daten kommen von der Diskette dann ganz einfach nicht runter. Vom Timingverhalten betreffend (bei neuen Rechnern nicht mehr vorhandenen) HW-Schnittstellen in virtualisierten Umgebungen mal ganz abgesehen, insb. wenn es um Programmieradapter geht.

Ein DOS als VMWare laufen zu lassen ist kein Thema, falls Du das tatsächlich relativ interessant findest: iso-Image von Freedos.org ziehen und Du hast Deine DOS-Maschine in ungefähr 5 Minuten laufen, was auch immer Du damit machen willst. Aber darum geht's hier nicht.

Beste Grüße
Tjareson

Hallo Micha,

daran hatte ich auch schon kurz gedacht. Aber das Passwort besteht nur aus Zeichen, welche dafür eigentlich nicht anfällig sein sollten.
Also keine Umlaute, Sonderzeichen etc.
Leeres Passwort (also auf QNAP und DOS) führt übrigens zu gleichem Ergebnis.

Ich habe mittlerweile auch noch eine Anleitung gefunden (ich glaube von QNAP selbst), dass man DOS LAN Manager Authentifizierung in der smb.conf aktivieren muss (lanman auth = yes und client lanman auth = yes). Klang schlüssig, brachte nur leider kein anderes Ergebnis. Angeblich sollen die Netzwerkpasswörter unter DOS eine andere / schwächere Verschlüsselung haben, weswegen es mit Samba nicht wirklich funktioniert. Dahingehend habe ich aber nichts detaillierteres gefunden. Und Richtung XP geht es ja auch, mit und ohne Passwort... Sonderbar ist das alles.

tomas: Na klar ist das alt, aber das war hier im Thread nicht die Frage. Und schon mal ein physikalisches 3.5"-Laufwerk oder eine parallele Schnittstelle virtualisiert? Wer mal was mit Entwicklungsumgebungen für eingebettete Systeme und deren Programmierung mit Bit-Banging gemacht hat, wird das auf Anhieb nachvollziehen können. Der Rest hilft dem hier diskutierten Sachverhalt nicht wirklich weiter.

Beste Grüße.
Tjareson

Hallo,

hat hier eigentlich mal einer Erfolg gehabt, sich mit einem DOS-Client zu einem QNAP zu verbinden?

Ich habe einen alten DOS-Rechner inkl. dem MS-Netzwerkclient wieder zum laufen bekommen und kann mich von dort per net use zum Beispiel auf die auf einem XP-Rechner freigegebenen Shares ohne Probleme verbinden.
Nur Richtung QNAP geht das nicht. Ich bekomme immer die Meldung, dass das Passwort falsch sei, übrigens auch dann, wenn ich bei net use Shares angebe, welche auf dem QNAP gar nicht existieren...
(Auf das gleiche QNAP Share kann ich mich jedoch von XP, Windows 7 und Ubuntu sofort ohne Probleme verbinden.)

Irgendetwas läuft in der Kombination MS-Netzwerk-Client unter DOS und QNAP anders ab, ich habe aber keine Idee, was das sein könnte. Auf jeden Fall versucht sich der DOS Netzwerkclient am QNAP anzumelden: Die fehlgeschlagenen Versuche sind im QNAP-Log zu sehen, mehr jedoch leider nicht. Fehlt QNAP irgendetwas, was zum Beispiel ein handelsübliches XP hat, weshalb ich zu letzterem verbinden kann, zu QNAP jedoch nicht?

Beste Grüße.
Tjareson