[Gelöst]Modul 93_DBRep gzip failed: cannot open file Permission denied

Begonnen von drul, 25 November 2023, 18:33:15

Vorheriges Thema - Nächstes Thema

drul

Hallo,
ich habe es gestern nach langem Suchen endlich geschafft meine auf einer qnap Nas laufende mariadb5 mit obrigem Modul zu sichern. FHEM läuft auf einem raspberry. Leider ist der generierte dump-file von user und gruppe "root". Das führt dazu, dass die nachfolgenden Schritte nicht mehr ausgeführt werden (Permission denied). Habe ich einen Gedankenfehler, oder müsste die Datei nicht dem beim FHEM angemeldeten user gehören?

DS_Starter

Die erzeugten Dumpfiles gehören dem user fhem und der Gruppe dialout und werden mit diesen Rechten erzeugt (Beispiel meiner Installation):

-rw-r--r--  1 fhem dialout           57801056 Nov 23 23:10 syslogDB_history_2023_11_23_23_10.csv.gzip
-rw-r--r--  1 fhem dialout          170768867 Nov 24 00:06 fhemshort_2023_11_23_23_30.sql.gzip
-rw-r--r--  1 fhem dialout          142245560 Nov 24 00:07 fhemshort_history_2023_11_24_00_06.csv.gzip
-rw-r--r--  1 fhem dialout           57982638 Nov 24 23:10 syslogDB_history_2023_11_24_23_10.csv.gzip
-rw-r--r--  1 fhem dialout          170773024 Nov 25 00:09 fhemshort_2023_11_24_23_30.sql.gzip
-rw-r--r--  1 fhem dialout          142255171 Nov 25 00:10 fhemshort_history_2023_11_25_00_09.csv.gzip
-rw-r--r--  1 fhem dialout          425485946 Nov 25 19:15 fhem_history_2023_11_25_19_10.csv.gzip

Welche Methode verwendest du, clientSide oder serverSide? Die Files im Beispiel mit "csv" im Namen sind serverSide Dumps.
Das gemountete Dumpverzeichnis muß dem fhem User volle Zugriffsrechte gewähren.
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

drul

Ich habe bisher nur Serverside probiert.
Das dumpverzeichnis auf der NAS liegt im homeverzeichnis des benutzers "fhem". Dies ist der mariadb benutzer und ebenfalls der angemeldete FHEM Benutzer auf dem Raspberry. Die logfiles von FHEM werden als user "fhem" mit gruppe "users" angelegt.
Bei mir sieht das so aus:
-rwxr-xr-x 1 root root 671386278 Nov 24 21:39 fhem_history_2023_11_24_21_39.csv
-rwxr-xr-x 1 root root 671593023 Nov 24 21:47 fhem_history_2023_11_24_21_47.csv
-rwxr-xr-x 1 root root 671694272 Nov 24 21:51 fhem_history_2023_11_24_21_50.csv
-rwxr-xr-x 1 root root 673110598 Nov 24 22:38 fhem_history_2023_11_24_22_38.csv
-rwxr-xr-x 1 root root 667159671 Nov 25 17:38 fhem_history_2023_11_25_17_37.csv
-rwxr-xr-x 1 root root 668562222 Nov 25 18:29 fhem_history_2023_11_25_18_29.csv

DS_Starter

Die serverSide Dumps werden durch FHEM initiiert, aber durch den MariaDB Server direkt erstellt (https://mariadb.com/kb/en/select-into-outfile/).
D.h. die Rechte der erstellten Files werden in diesem Fall nicht durch FHEM gesteuert. Nur die daraus erstellten optionalen gzip-Files werden wiederum durch FHEM gesteuert.

Nun kenne ich QNAP nicht, d.h. ich weiß nicht ob man den Server überreden kann auch der "Welt" Schreibrechte auf die Files zu geben damit fhem die csv-Quellen nach Komprimierung löschen kann.
Lesen sollte ja für die "Welt" mit den bestehenden Rechten (-rwxr-xr-x) funktionieren, d.h. die Erstellung der gzip-Files sollte klappen, nur das Löschen der csv-Quellen wird mit "Acces denied" verwehrt.

Du kannst auch auf die integrierte Versionsverwaltung (Attribut "dumpDirLocal" nicht setzen) verzichten und dir eine eigene Löschverwaltung auf dem NAS überlegen falls der obige Weg zu steinig sein sollte.
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

drul

Ich habe mich mit den usern "fhem" und "uli" über ssh an die NAS angemeldet und mit folgendem Befehl einen Dump angestoßen:
/mnt/ext/opt/mariadb5/bin/mysqldump -u user -pPasswort fhem | gzip -c >/share/CACHEDEV1_DATA/Haus/Fhem/mariadbTmp/dump.sql.zip
Damit habe ich folgende Dateien als Ergebnis bekommen:
-rw-rw---- 1 fhem  everyone        61637020 2023-11-29 17:19 dump_1718.sql.zip
-rw-rw---- 1 uli   everyone        60665705 2023-11-28 14:00 dump_1400.sql.zip

Die folgende Datei wurde über den dump mittels modul erstellt in das gleiche Verzeichnis erstellt:
-rw-rw-rw- 1 admin administrators 657348310 2023-11-28 10:18 fhem_history_2023_11_28_10_18.csv

Ich habe keine Idee wie der Anstoß über das Modul funktioniert.

DS_Starter

Das Äquivalent zu /mnt/ext/opt/mariadb5/bin/mysqldump mittels des Moduls wäre ein

  dumpMySQL clientSide 

Dadurch entsteht ein SQL-File unter Steurung des Moduls was dem Ergebnis vom mysqldump entspricht.
Die serverSide Option stößt den Dump im MySQL-Server an wie die Doku im oben verlinkten Hinweis es beschreibt.
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

drul

Beide Varianten (server_side und Client_side) funktionieren jetzt, nachdem ich dem NAS-User Adminrechte zugewiesen habe.
Das Problem liegt also an den Usereinstellungen auf der Qnap-NAS. Der User benötigt Adminrechte auf der NAS. Bedeutet:

Erstelle ich einen Dump als Datenbankuser ohne Adminrechte bzw. ohne gleichnamigen User auf der NAS, wird der Dump mit den Eigenschaften des NAS-Admin im Zielverzeichnis angelegt. Hat der Datenbankuser=NAS-User Adminrechte auf der NAS, so wird der Dump mit den Eigenschaften des NAS-Users im Zielverzeichnis angelegt.

Die Lösung ist nicht gut da unsicher (User hat Adminrechte auf der NAS), aber ich habe keine Idee wie, oder mit welchen Einstellungen das zu ändern wäre