Backitup v1.8.5 0kB
-
@ofbeqnpolkkl6mby5e13 said in Backitup v1.8.5 0kB:
@simatec
Okay, dann ist doch alles richtig. Stellt sich eben nur die Frage, weshalb nach einem Update des JS-Controllers die Berechtigung zum Erstellen des Ordners "/opt/iobroker/node_modules/iobroker.js-controller/tmp/backup" wieder weg ist. Ist ja leicht durch "iobroker fix" zu beheben, aber ich kann mich nicht erinnern, dass das vor JS-Controller 3.2.X so war.Das könnte an der Art liegen, wie du den JS-Controller installiert hast. Ich habe den heute allerdings auf alle möglichen Arten installiert und keine Probleme feststellen können, der tmp Ordner hatte immer die Berechtigungen rwxr-xr-x iobroker iobroker, ich konnte es also nicht nachvollziehen
-
@fastfoot
Hmm. "npm i iobroker.js-controller@next"Der nächste JS-Controller kommt bestimmt. Ich bin gespannt!
drwxr-xr-x iobroker iobroker
Danke für deine Mühe!
-
@ofbeqnpolkkl6mby5e13 said in Backitup v1.8.5 0kB:
@fastfoot
Hmm. "npm i iobroker.js-controller@next"Der nächste JS-Controller kommt bestimmt. Ich bin gespannt!
drwxr-xr-x iobroker iobroker
Danke für deine Mühe!
Dann wäre es interessant zu wissen, wie dann der Ordner vor dem fix geflaggt ist. Ansonsten empfehle ich
iob update && iob upgrade selfanstatt über npm, das hatte aber bei meinen Tests, den Fehler zu provozieren, nichts gebracht -
@fastfoot said in Backitup v1.8.5 0kB:
Dann wäre es interessant zu wissen, wie dann der Ordner vor dem fix geflaggt ist.
Ich werde berichten!
-
Installation von JS-Controller 3.2.11, selber Fehler.
Vor Installation:
Gestartet... [DEBUG] [iobroker] - host.iobroker-d 12765 states saved [DEBUG] [iobroker] - host.iobroker-d 18332 objects saved [DEBUG] [iobroker] - Backup created: /opt/iobroker/backups/iobroker_2021_01_28-19_31_42_backupiobroker.tar.gz [DEBUG] [iobroker] - done [DEBUG] [clean] - done [DEBUG] [telegram] - done [DEBUG] [historyHTML] - new history html values created [DEBUG] [historyHTML] - done [DEBUG] [historyJSON] - new history json values created [DEBUG] [historyJSON] - done [EXIT] 0# pwd /opt/iobroker/node_modules/iobroker.js-controller # ls -la drwxr-xr-x 2 iobroker iobroker 4096 Jan 28 19:31 tmpNach der Installation:
Gestartet... [DEBUG] [iobroker] - host.iobroker-d 12765 states saved [ERROR] [iobroker] - Uncaught Rejection: Error: EACCES: permission denied, mkdir '/opt/iobroker/node_modules/iobroker.js-controller/tmp/backup' at Object.mkdirSync (fs.js:841:3) at /opt/iobroker/node_modules/iobroker.js-controller/lib/setup/setupBackup.js:300:32 at processTicksAndRejections (internal/process/task_queues.js:97:5) [DEBUG] [iobroker] - done [DEBUG] [clean] - done [DEBUG] [telegram] - done [DEBUG] [historyHTML] - new history html values created [DEBUG] [historyHTML] - done [DEBUG] [historyJSON] - new history json values created [DEBUG] [historyJSON] - done [EXIT] 6# pwd /opt/iobroker/node_modules/iobroker.js-controller # ls -la drwxr-xr-x 2 root root 4096 Jan 28 19:39 tmp -
Ach so, es ist nur der "tmp"-Ordner, der danach auf root steht:
# ls -la insgesamt 512 drwxr-xr-x 6 iobroker iobroker 4096 Jan 28 19:40 . drwxrwxrwx 1172 iobroker iobroker 36864 Jan 28 19:39 .. -rw-r--r-- 1 iobroker iobroker 84725 Okt 26 1985 CHANGELOG.md -rw-r--r-- 1 iobroker iobroker 420 Okt 26 1985 compactgroupController.js drwxr-xr-x 2 iobroker iobroker 4096 Jan 28 19:38 conf -rw-r--r-- 1 iobroker iobroker 158 Okt 26 1985 controller.js -rw-r--r-- 1 iobroker iobroker 8341 Okt 26 1985 gulpfile.js -rw-r--r-- 1 iobroker iobroker 74 Okt 26 1985 iob -rwxr-xr-x 1 iobroker iobroker 33 Okt 26 1985 iobroker.js -rw-r--r-- 1 iobroker iobroker 5 Jan 28 19:40 iobroker.pid -rw-r--r-- 1 iobroker iobroker 59436 Okt 26 1985 io-package.json drwxr-xr-x 10 iobroker iobroker 4096 Jan 28 19:38 lib -rw-r--r-- 1 iobroker iobroker 1135 Okt 26 1985 LICENSE -rw-r--r-- 1 iobroker iobroker 207604 Okt 26 1985 main.js drwxr-xr-x 50 iobroker iobroker 4096 Jan 28 19:38 node_modules -rw-r--r-- 1 iobroker iobroker 6476 Jan 28 19:38 package.json -rw-rw-rw- 1 iobroker iobroker 156 Jan 28 19:42 pids.txt -rw-r--r-- 1 iobroker iobroker 45055 Okt 26 1985 README.md -rw-r--r-- 1 iobroker iobroker 5677 Okt 26 1985 reinstall.js drwxr-xr-x 2 root root 4096 Jan 28 19:39 tmp -
Da sind ja ACLs gesetzt. Schau mit
gefacl /opt/iobroker/node_modules/iobroker.js-controller/tmpnach den vollständigen Rechten.
Schreibrechte der Gruppe fehlen übrigens schon in deiner ersten Version.
-
# getfacl /opt/iobroker/node_modules/iobroker.js-controller/tmp getfacl: Entferne führende '/' von absoluten Pfadnamen # file: opt/iobroker/node_modules/iobroker.js-controller/tmp # owner: root # group: root user::rwx group::r-x other::r-x -
@ofbeqnpolkkl6mby5e13
Okay...
Richtig sähe das so aus:pi@raspberrypi:/opt/iobroker/node_modules/iobroker.js-controller $ getfacl tmp/ # file: tmp/ # owner: iobroker # group: iobroker user::rwx group::r-x group:iobroker:rwx mask::rwx other::r-x default:user::rwx default:group::r-x default:group:iobroker:rwx default:mask::rwx default:other::r-x -
Okay.
Ist schon komisch. Eigentlich ist es aber auch egal, denn nach iobroker fix geht es ja jedes Mal wieder. Und den JS-Controller aktualisiert man jetzt auch nicht alle Tage.
-
@fastfoot
Ohne mit weiteren Logs zu langweilen. Mit "iobroker upgrade self" tritt der Fehler nicht auf. Vielen Dank! -
@ofbeqnpolkkl6mby5e13 sagte in Backitup v1.8.5 0kB:
@fastfoot
Ohne mit weiteren Logs zu langweilen. Mit "iobroker upgrade self" tritt der Fehler nicht auf. Vielen Dank!gut zu lesen! Meine Vermutung war ja dass man im Falle der npm installation ja nicht der user iobroker ist und sich deshalb die Berechtigungen des tmp Ordners ändern. So einfach ist es aber wohl nicht, denn in meinen Tests hatte ich den Ordner auch vor der Installation gelöscht und dennoch war er richtig mit iobroker:iobroker geflaggt, auch bei einer npm Installation. Gerade weil unsere Setups durch Container auf QNAP sehr ähnlich sind, hatte mich das verwundert
-
@fastfoot
Ich verstehe auch nicht, weshalb ausschließlich der tmp-Ordner betroffen ist.Ganz vielen Dank für deine Hilfe und Beharrlichkeit!
Auch danke an @thomas-braun, der trotz seiner Container-Abneigung noch mal geholfen hat!
-
@thomas-braun sagte in Backitup v1.8.5 0kB:
Richtig sähe das so aus:
das hat mich jetzt doch mal interessiert, mit acl's kenne ich mich aber Null aus. Scheinbar liegt das nicht (nur) am Container, sondern auch daran dass die QNAP das generell nicht nutzt. Alle Angaben von getfacl sehen auch auf dem Host so aus wie von @oFbEQnpoLKKl6mbY5e13 gezeigt, die von dir gezeigten Zusatzangaben fehlen nicht nur bei den shared ordnern sondern auch in reinen Linux Ordnern wie /bin, /sbin etc. Die nutzen auch keine Standard Distro, uname -a sieht dann so aus: Linux qnapnas 4.14.24-qnap #1 SMP Thu Jan 7 01:26:20 CST 2021 x86_64 GNU/Linux
-
@fastfoot Auf welchem Dateisystem läuft denn das da?
-
@thomas-braun sagte in Backitup v1.8.5 0kB:
@fastfoot Auf welchem Dateisystem läuft denn das da?
jetzt hast du mich erwischt
ein Eintrag aus dmesg lautet so. ist bei mir ein Raid5
EXT4-fs (sdd1): mounting ext3 file system using the ext4 subsystem -
@fastfoot Also ein erweitertes ext3. Keine Ahnung was da genau getrieben wird. Mit ACL bin ich aber auch nicht auf Du und Du. Aber es scheint da einen Zusammenhang zu geben.
-
@fastfoot
Kann es an npm liegen?# npm -v 6.14.11 -
@ofbeqnpolkkl6mby5e13 sagte in Backitup v1.8.5 0kB:
@fastfoot
Kann es an npm liegen?ich habe die 6.14.10, glaube aber nicht. Vielleicht finden die Entwickler ja noch die Ursache, wenn das häufiger auftritt. Aber jetzt läuft es ja, ich upgrade npm eigentlich auch immer recht zeitnah, habe aber viel mit meinen diversen Containern rumgespielt und ständig gewechselt, die buanet images kommen ja noch mit der .10 und ich habe noch nicht geupdated. Ist ja aber auch nicht soo wichtig normalerweise, man merkt im Normalfall ja keinen Unterschied
