Beiträge von marky0736

Hat jemand eine Lösung für dieses Problem gefunden? Ich habe das genau wie beschrieben seit dem Firmware Update auch. Alle Windows Clients können in den Shares nicht suchen, bzw. finden nichts. Vor dem Update ging es auf allen.

Habe im Netz noch das gefunden, aber die haben auch keine Lösung gefunden:

Aus der Community qnap auf Reddit

Entdecke diesen Beitrag und mehr aus der Community qnap

www.reddit.com

Falls jemand das Problem auch haben sollte, hier die Lösung: MariaDB 10 aus dem App Center installieren. Neue Datenbank anlegen, MariaDB stoppen, bestehenden Ordner "data" im MariaDB Verzeichnis umbenennen und einen Link namens "data" auf den QMariaDB-Share setzen oder die Daten aus dem QMariaDB-Share in einen neuen Ordner "data" kopieren. Nach dem Neustart von MariaDB sind dann alle Daten in MariaDB 10 da.

Habe leider keine Ahnung, was das genau war. Ich hatte das damals zuerst mit dem "normalen" MariaDB probiert und nicht hinbekommen. Daher hat mir jemand im Kodi-Forum einen Link zu dem QPKG von QMariaDB geschickt und mir bei der Einrichtung geholfen. Wie gesagt, ich verstehe wirklich überhaupt nichts davon. Wenn ich die Datenbank irgendwie ins "normale" MariaDB bekommen könnte, wäre vielleicht auch schon etwas gewonnen, aber so komme ich irgendwie gar nicht mehr an die gesamten Daten. Oder sollte ich ein Downgrade zu 5.0.0.1891 machen? Aber da bekomme ich bei QNAP schon die Firmware gar nicht mehr... So ein Mist...

Es gibt auch wohl eine neuere Version, aber der Link ist offline. Da steht auch irgendwie, wo die Daten sind, aber wie bekomme ich die migriert?

[ QMariaDB ] [ 10.5.11 ] MariaDB Server (wth PhPMyadmin) - QNAP NAS Community Forum

Hallo und schonmal vielen Dank,

die alte Version weiß ich nicht mehr. Er hat zwei Firmware-Updates hintereinander gemacht. Jetzt ist 5.1.4.2596 drauf.

Auf der von Dir verlinkten Seite gibt es leider auch kein Update. Da gibt es zwar MariaDB, ich hatte aber QMariaDB benutzt, daher hilft mir das nicht. Oder bin ich doof?

Grüße

Ergänzung: Die alte Version war laut Protokoll 5.0.0.1891 (20211221).

Hallo zusammen!

Heute hatte ich endlich mal wieder ein wenig Zeit und habe die inzwischen völlig überholte Firmware meiner TS-853A auf den neuesten Stand gebracht.

Nach dem Neustart konnte ich nicht mehr auf meine Datenbank für kodi zugreifen. Auch mit phpMyAdmin gab es keine Verbindung mehr.

Im App Center habe ich jetzt gesehen, dass QMariaDB (version 10.5.4.0) nicht gestartet ist. Wenn ich auf den "Start Knopf" drücke, braucht es ein wenig und dann bekomme ich die Fehlermeldung

"Failed to start QMariaDB. QTS does not support this QMariaDB version. Check for updates in "App Center" or on the official app website."

Leider kann ich aber nirgendwo ein Update finden für QMariaDB. Vielleicht kann mir jemand helfen. Wo bekomme ich das her?

Muss vielleicht dazu sagen, dass ich den ganzen Datenbank-Kram nicht wirklich blicke. Ich habe mir diese Datenbank vor ein paar Jahren mit viel Hilfe aus dem Forum eingerichtet und war gottfroh, dass sie so stabil lief. Könnte mich jetzt schon ohrfeigen, das Update gemacht zu haben...

Grüße

So, habe jetzt die MariaDB-Version aus dem Clubstore installiert. Funktioniert einwandfrei und ist mir die 8 Euro dann am Ende auch wert. Für alle, die sie auch testen wollen, sie ist im my.cnf so konfiguriert, dass der Server nur Verbindungen vom localhost zulässt - hat mich einige Zeit gekostet, das herauszufinden.

Vielleicht wäre das hier eine einfachere Lösung? Hat das schonmal jemand probiert?

[ QMariaDB ] [ 10.5.4 ] MariaDB Server (wth PhPMyadmin)

oder das?

MySQL Server

Danke!

Wenn ich den zweiten Link überfliege, weiß ich schon sicher, dass ich das niemals hinbekommen werde!

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

Zitat von jumpooger

Ein andere Möglichkeit wäre noch die Container Station mit SQL als Docker.

Das klingt nicht einfach. Gibt es irgendwo eine Anleitung für Anfänger, wie das geht?

Hallo alle zusammen,

die Suchfunktion habe ich benutzt, aber entweder ich bin zu dumm, die richtigen Begriffe zu benutzen, oder es gibt tatsächlich noch nichts dazu.

Auf meiner TS-853A / 16 GB / Celeron N3150 @ 1.60 GHz / QTS 4.5.1.1456 läuft die SQL-Version, die bei der Firmware dabei ist. Mit dieser habe ich nun eine Datenbank für meine Kodi-Geräte im Netzwerk aufgebaut, was soweit auch geklappt hat. Leider ist die SQL-Version sehr alt und macht offenkundig Probleme, denn der Zugriff ist grauenvoll langsam. Zum Test habe ich auf einer Windows-VM mal die neuste SQL-Version installiert, die läuft deutlich schneller, aber natürlich ist das keine Dauerlösung.

Daher die Frage, wie komme ich zu einer neueren SQL-Version, die auch nach einem Firmware-Updae weiterläuft? Bin dankbar über jede Hilfe und eine Erklärung für Dummies.

Grüße

Danke für den Tipp, aber da hatte ich Angst, dass er an den Einstellungen für die Ordner, die noch da sind, wieder etwas zurücksetzt. Nach mehrmaligem Hochfahren ist der home-share auf einmal wieder da, das verstehe wer will. Für die Zukunft auch blöde, dass ich nicht weiß, woran es lag. Naja, fürs Erste tut es mal wieder, mal sehen wie lang.

Danke und Grüße,
Marky.

Hallöchen,

nachdem ich meine TS-853A (Firmware 4.3.1. 20160601) neu starten wollte und nach einer Stunde immer noch "Rebooting System" im Display stand, habe ich ihr den Strom abgedreht und sie neu hochgefahren. Soweit funktioniert auch alles, aber mein "home" share ist verschwunden. Die Daten liegen noch unter /homes/admin/, aber da diverse Programme auf den home-share zugreifen, will ich diesen ebenfalls wiederherstellen. Die Virtualization Station funktioniert auch nicht, aber ich hoffe mal, dass das mit dem fehlenden home-share zusammenhängt. Kann mir jemand sagen, wie ich den home-share wiederbekomme?

Grüße,
Marky

Hallöchen,

habe beides probiert. Manuell kommt die oben genannte Meldung, in dem Task, der jede Nacht läuft heißt die Meldung nur lapidar "failed to create snapshot".

Mittlerweile habe ich den Verdacht, dass die Meldung vielleicht gar nicht so unberechtigt ist. Habe alle älteren Snapshots gelöscht, bekomme die Meldung immer noch und in der Speicherplatzübersicht werden mir immer noch 1.4 TB an Momentaufnahmen angezeigt.

Gibt es eine Möglichkeit die alten Snapshots über SSH zu löschen? Weiß jemand, wo die abgelegt sind?

Das habe ich zwar auch gelesen, jedoch hab ich den Fehler trotz der neuesten Firmware immer noch. So ein Mist.

Hat schon jemand eine Lösung gefunden? Habe das Problem ebenfalls, aber weder Zeit noch Lust, die ganze Kiste neu aufzusetzen!

Hallöchen,

danach habe ich ebenfalls stundenlang in verschiedenen Foren gesucht, leider ohne Ergebnis.

Falls Du auf der VM Windows drauf hast, würde ich nicht lange rumsuchen, sondern einfach die Testversion von Acronis True Image installieren und ein Image erstellen. Dann eine neue VM aufsetzen, Windows drauf, True Image drauf und wiederherstellen. Das geht eigentlich alles recht schnell, wenn man nicht davorsitzt und wartet. Mit dem Windows-eigenen Imagetool funktioniert es übrigens nicht, das hatte ich zuerst ausprobiert - das kann nur auf größere Partitionen zurückspielen

Grüße,
Marky.

Hallöchen,

da ich für das englischsprachige QNAP-Forum eine Anleitung erstellt habe, möchte ich diese auch hier posten, da schon öfter gefragt wurde, wie man Schlüssel/Passwort an anderen Stellen als auf dem Gerät selbst speichern kann. Zum Übersetzen ist es mir jetzt etwas zu lang, aber ich denke, die meisten können ausreichend Englisch, um zu folgen. Natürlich kann man die einzelnen Elemente der Anleitung auch für andere Einsatzzwecke als verschlüsselte RTRR-Backups nutzen.

Grüße,
Marky.

-------------------------------------------------------

Hiya,

after spending hours on getting this to work, I decided to put together a quick tutorial on how you can mount encrypted volumes with a keyfile that is not stored on the NAS itself. Most of the information that is needed to do this is spread across this forum, the German forum and some other sites.

First, let me outline my current configuration and what it does:

Setup:
- NAS Main Server, encrypted file system, has to be manually entered after boot. Never powered down, used as main server on the network.
- Backup NAS, encrypted file system, auto-mounted after boot. Usually powered off, wakes up once a week to do an rtrr-backup of the main server.

The main point is that the keyfile to mount the Backup NAS is not stored on the Backup NAS itself, but on the Main Server, so if the main server is powered down, the Backup NAS' encrypted volumes won't be mounted automatically (of course you can do so manually through the Web-GUI). I still wonder why QNAP won't allow useres to utilize keyfiles on a remote share or USB device, but anyhow, here's how to do it.

The following steps are a brief summary on what you have to and require some proficieny.

1.) Create Keyfile

The first thing you do is create a keyfile. SSH into the NAS you want to mount automatically and create it:

storage_util --encrypt_pwd pwd=YOUR_PASSWORD > /tmp/keyfile.key

where

YOUR_PASSWORD is the password you use to mount your encrypted devices on the NAS

The result will be an encoded keyfile which will later be used to automount the volumes. Please note that this keyfile is not identical to the keyfile you can download with the storage manager's download-function!!! It contains your Password in encrypted form.

Make sure your keyfile does not have linefeed at the end of the password. Load it into vi or use Windows notepad to make sure.

2.) Copy Keyfile to secure Location and create Backup User

The next thing you want to do is copy the keyfile you just produced to its final destination. The safest place in my opinion is the Main NAS, which can only be decrypted by manually entering the password after boot.

So what you want to do is create a share, e.g. "BackupMount" on your Main NAS and copy the keyfile into this share.

Next you want to create a user that will later access the keyfile on your Main NAS to mount the encrypted volumes on your Backup Nas. In this example, we'll create a user called "BackupNAS". Make sure the password for this user is absolutely unique. This password should not be identical to any password used to decrypt volumes or gain access rights to your NAS because this will later be available in plain text to possible intruders!!! In this example, this password is USERPASS.

Limit access for this user to the share which holds the keyfile. This should be the only share with access rights for this user (Read-Only is enough). Do not grant access to this share to any other users on the NAS.

3.) Write automount-script

The next thing to do is create an automount-script that will later be called on system startup on the Backup-NAS.

In this example it would look like this:

#!/bin/shmkdir /keylocationmount.cifs //192.168.0.5/BackupMount /keylocation -o username=BackupNAS,workgroup=WORKGROUP,password=USERPASScryptsetup -v luksOpen /dev/mapper/cachedev1 ce_cachedev1 --key-file=/keylocation/keyfile.key --key-slot 0mkdir /share/CE_CACHEDEV1_DATAmount -t ext4 /dev/mapper/ce_cachedev1 /share/CE_CACHEDEV1_DATA//etc/init.d/init_lvm.sh

where

192.168.0.5 is the IP-Adress of you Main NAS (the place you stored the keyfile on)
BackupMount is the share you created on this device and stored the keyfile in
BackupNAS is the username you created on this device and
USERPASS is the password for this user
keyfile.key is the keyfile you created in step 1
WORKGROUP of course is the workgroup name of your samba network.

In this example, we'll call the script automount.sh

Again, make sure your script does have correct linefeeds. Either load it in vi or edit it on Windows, but make sure it's properly formatted afterwards. If you're unsure if it's okay, use dos2unix (download from sourceforge) to make sure it's properly formatted.

4.) Copy automount-script on persistent device

As we want to execute this script on startup later, it's important that you store it on a device that is not replaced by flash-memory after reboot. The best option is a USB-Stick, as you can quickly pull it out if you don't want your device to be automatically decrypted for whatever reason.

So put the USB-Stick into your Backup-NAS and format it with ext4. Otherwise you might have problems with making the script executable.

Copy the automount-script on the USB-Stick. Again: Make sure it's properly formatted for linux (see above).

ssh into your Backup-NAS and find the USB-Stick first (it's in /share/external/). Note the device name of the USB-Stick. You will need it later.

Make the script executable using

chmod +x automount.sh

You might now want to test the script. Please note:
- the script can't be executed from the current directory, so "automount.sh" won't work. Use "./automount.sh" to test it.
- the last step in the script might take a while (2-3 minutes) smoke a cigarette or have a cup of coffee in the meantime. Don't lose patience.

5.) Setting up auto-execution of the script

Now this is a little bit dirty, but it's what I found and it works although I don't really like its implementation.

Go to /etc/conf/

Edit the file "qpkg.conf"

Append the following section:

[CryptMount]
Name = CryptMount
Version = 0.1
Author = marky
Date = 2016-01-01
Shell = /share/external/DEV3301_0/automount.sh
Install_Path = /share/external/DEV3301_0
Enable = TRUE

where
DEV3301_1 ist the device name of the USB-Stick you noted above

As you can see, most of the information is unimportant, only Shell and Install_Path are relevant.

6.) Final check.

Now you can reboot your Backup-NAS and be patient. After some time you will be able to access all shares and even store manager will show the volume with an open lock.

Of course it's up to you what to do next, set up a time schedule for unattended backups with no need for interaction or just adjust the procedure to your needs.

That's it for now, I'm sure I forgot something, but it's quite a longish procedure to describe.

Enjoy,
Marky.

Die Option zur Rettung von Restdaten habe ich ohnehin als hoffentlich nie notwendiges Ereignis relativ weit hinten angestellt, siehe die Ausgangskonfiguration; schließlich werden die Backups nicht täglich neu geschrieben und das Risiko, das im NAS mehr als zwei Platten ausfallen und gleichzeitig eine der vier im Backup-Verbund erscheint mir überschaubar. In meinem Keller liegen Generationen von ausrangierten Platten, die aber alle noch laufen, obwohl sie mohrenalt sind und jede Menge Betriebsstunden auf dem Buckel haben (im Schnitt 5-6 Jahre 24/7 in einem Windows-Server). Die Dinger sind doch allgemein zäher als man so denkt. Wenn es um Firmendaten geht, ist das sicherlich etwas anders, aber für einen Privatanwender scheint mir das Risiko überschaubar, auch mit SMR-Platten.

Mittlerweile komme ich ohnehin zu dem Schluss, dass ich noch einen Hunderter drauflege und mir eine TS-431 hole, dann kann ich die Kiste zeitgesteuert hochfahren für das Backup, das Backup verschlüsseln, die Kiste auch in einem anderen Raum parken und im Schadensfall sofort auf die Daten zugreifen, während das NAS sein RAID wiederherstellt.

Danke Matthias jedenfalls für die guten Gedanken, das hat mich letztendlich dann zu diesem Lösungsansatz gebracht! :thumb:

Grüße,
Marky

Den Gedanken mit JBOD hatte ich auch schon, allerdings verstehen leider alle Hersteller etwas anderes unter dem Begriff; bei manchen ist es eine Ansammlung von Platten, die als ein logisches Volume anliegen (Spanning), bei anderen wiederum stehen lediglich mehrere Einzelplatten zur Verfügung, was für meine Zwecke natürlich vollkommen nutzlos wäre. Es gibt von Raidsonic das gleiche Gehäuse auch als JBOD-Version, aber so wie ich das verstehe, melden sich die Platten dann eben einzeln am System an. Das ICY BOX IB-RD3640SU3 bietet "Spanning" (BIG) als Modus an, das wäre dann vielleicht die sicherere Alternative zu RAID 0 mit SMR-Platten. Aber ob man damit im Fall eines Ausfalls wirklich noch an die Daten auf den anderen Platten kommt?

Grüße,
Marky.

Hallöchen zusammen,

nachdem ich mit Hilfe der Suche keine Antwort zu meinem Problem finden konnte, erstelle ich hier mal einen neuen Post.

Seit einiger Zeit betreibe ich ein TS-853A mit 8x6TB WD Red Platten im RAID 6 für meine privaten Daten. Nun bin ich nach dieser für mich gewaltigen Investition auf der Suche nach einer bezahlbaren Backup-Lösung, um die 30 TB Daten in regelmäßigen Abständen zu sichern.

Ein paar grundsätzliche Voraussetzungen vorneweg:
1.) Preis bis 1200 Euro.
2.) Das Backup soll alle Daten, die auf dem NAS sind, beinhalten. Löschen, sortieren, Auswahl treffen etc. kommen nicht in Frage, ich sichere schon immer grundsätzlich alle meine Daten, zu Amiga-Zeiten mit Disketten und Zip, später mit DAT und auch heutzutage will ich über ein Vollbackup verfügen (vermutlich habe ich durch diese Backupstrategie im Lauf der Jahrzehnte 30 TB private Daten angesammelt ).
3.) Das Backup soll nur 1-2 Mal pro Monat geschrieben werden und einen Notanker darstellen, falls bei der RAID 6 Neuerstellung ein Problem auftritt. Wirklich essentiell wichtige (berufliche) Daten sichere ich alle drei Stunden auf diverse andere Medien und ein Snapshot des TS erstelle ich ohnehin täglich.
4.) Cloud-Lösungen scheiden aus, ich lebe in der Pampa mit DSL 1000.

Meine bisher einzig realistische Idee ist, ein Raidsonic ICY BOX IB-RD3640SU3 Gehäuse mit 4 Seagate Archive 8 TB Platten in einem RAID 0 zu bestücken und über USB 3.0 ab und an ein Backup zu schreiben, das ich dann an einem anderen Platz lagern kann.

Mir ist natürlich bekannt, dass RAID 0 relativ riskant ist, da die SMR Platten aber im RAID ohnehin problematisch sind, habe ich so für mich die Hoffnung, dass sich das in einem RAID 0 am wenigsten auswirkt, auch angesichts der Tatsache, dass das Backup ja nur 1-2 Mal pro Monat erstellt werden soll. Zudem gewinne ich etwas Geschwindigkeit und kann die Kapazität komplett nutzen, was die Lösung natürlich wieder günstiger macht.

Daher nun meine Fragen:
1.) Hat jemand eine solche Lösung laufen und irgendwelche Erfahrungen damit?
2.) Falls nicht, wie beurteilt Ihr die Lösung?
3.) Kennt jemand eine alternative Möglichkeit im selben Preisrahmen? (Jukeboxes, LTO5/6, RDX etc. sind da wohl raus)
4.) Im Forum habe ich gelesen, dass Disk-Spanning-Backups mit Wechselfestplattenlaufwerken mit der QNAP Software nicht funktionieren. Stimmt das noch (waren meist ältere Posts)?

Besten Dank für Meinungen und Hilfe,
Marky.