Mini-HowTo: Cannot find view "system" for search "host"
-
@bavarian dir ist aber schon klar das es Betriebssystemproblem ist.. wenn bei schreibzugriff der strom weg ist.. DANN IST DAS SO
was soll der Host dann machen.. kein grundsatz problem UNSERSEITS. DU musst DAFÜR SORGEN dass die schreibzugriffe bis zu ende laufen ..
da ist eine USV nützlich..
das bekommen WIR nicht in Griff
-
@arteck
Das mit der GROßSCHREIBUNG lass mal sein, sowas ist unfreundlich, gehört sich nicht!
Ich habe extra geschrieben ich will niemanden Angreifen, dann verhalte Dich doch bitte professioneller.Fakt ist, ich betreibe in einem privaten Hobby Projekt Raspberry PI2 und Raspberry PI3+ welche kalt
ausgeschaltet werden weil es anders nicht ging. Dieses Projekt läuft bei gut 300 Leuten stabil ohne
dass es jemals zu Problemen kam, das ist Tatsache und keine Geschichte. Natürlich ohne IOB.Die Frage ist doch, warum es mit den PI3+ reproduzierbar eben nicht zu diesen Problemen kam.
Es liegt nicht am PI selbst, soviel ist klar, es liegt am Schreibvorgang während des Stromausfalls.
Hätte man das nicht mit einer Art Schattenkopie lösen können welche im Falle eines Stromausfalls
hätte genommen werden können, X Sekunden / Minuten vor dem unterbrochenen Schreibvorgang?
Ein Vergleich der Aktuellen Datei / DB und einer Schattenkopie mit passenden Parametern ist
doch problemlos realisierbar.Wie gesagt, es braucht hier keine Hitzige Diskusion und es ist kein Angriff, lediglich eine Objektive
Beobachtung eine Benutzers der nicht ganz unbedarft im Umgang mit der Technik ist. -
@bavarian Jetzt müssen wir das mal strukturiert auseinandernehmen (und nein fühle mich nicht angegriffen oder so, alles gut):
1.) Es ist bekannt und in diesem thread mehrfach gesagt worden das der js-controller 3.2 etwas anfällig ist für solche Probleme, aber seit js-controller 3.3 das Problem an sich nicht mehr auftritt - es gab bisher einen berichteten Sonderfall wo nach einem Crash dann beim Start sehr schnell ein weiterer crash passiert ist und durch sehr schlechtes Timing in dem Fall es Probleme gab auch mit Controller 3.3. ... Von daher: Problem bekannt, Lösung ebenfalls ... Damit ist es für mich sehr einfach: Falls Du noch js-controller 3.2 hast dann updaten und dein Problem sollte Geschichte sein. Und mit controller 4 und JSONL als DB sollte das ganze noch unproblematischer werden. Falls Controller 3.3 und es passiert regelmäßig dann würden mich da mal die Logs interessieren ... weil das würde ich gern verstehen wollen.
2.) Wenn du regelmäßige Stromausfälle hast und ein stabiles Smart-Home System brauchst dann investiere in eine USV ... weil mal ehrlich: Zu erwarten das jegliche Software mit harten crashes umgehen kann (und übrigens sei Froh wenn es dir dabei "nur" den ioBroker crasht und nicht das Dateisystem - weil wenn das passiert hast Du viel größere issues) ist etwas utopisch. Das garantiert dir niemand - vor allem wenn Du an Urlaub oder Dienstreisen denkst.
Aus meiner Sicht musst Du entscheiden was Du willst ... und dann das tun was du brauchst um das Ziel zu erreichen.
Die Optionen für ein Stabiles System liegen alle auf dem Tisch liegen -
@bavarian sagte in Mini-HowTo: Cannot find view "system" for search "host":
Fakt ist, ich betreibe in einem privaten Hobby Projekt Raspberry PI2 und Raspberry PI3+ welche kalt
ausgeschaltet werden weil es anders nicht ging. Dieses Projekt läuft bei gut 300 Leuten stabil ohne
dass es jemals zu Problemen kam, das ist Tatsache und keine Geschichte. Natürlich ohne IOB.Interessehalber: Und wie stellst Du das sicher das es nicht die SD Karte bzw das Dateisystem dabei zerreisst? Ja sowas kann man "bauen" mit nem Read only Filesystem als eigene Partition für den Statischen Teil und RAM Disks für den dynamischen Teil mit regelmäßigem Sync auf die Karte und damit "seltene kleine Zeitfenster" oder anderen aufwändigen Konstruktionen. Und ja wenn das einzig Dynamische Logfiles sind geht das ggf auch so ...
Wenn Du sowas nicht machst und das ein Standard SD image mit einer partition ist wo alles läuft dann haben die 300 User bisher in meinen Augen und meinen Erfahrungen nach großes Glück gehabt
-
@bavarian wow moment.. die Grossschreibung sollte DIR klar machen, dass DU für das laufende System verantworlich bist..
wenn dir Daten flöten gehen was hier der Fall ist bis DU dafür verantwortlich dies zu verhindern (hier mit einer USV)wenn DU selber weisst dass es zur Stromausfällen kommt dann verstehe ich die Aufregung nicht.. DU weisst doch wo das Problem ist und wir haben DIR die Lösung dazu geliefert ..
gefällt dir die Lösung nicht ?? oder wie soll ich das verstehen ??
wenn du schon 300 installationen durchgeführt hast und du so technick affin bist dann verstehe ich es erst recht nicht.. vor allem wenn man ein System an einen anderen User ausliefert sollte dieser so sicher sein wie möglich.. also USV davor (ja grossgeschrieben)
wie schon apollon77 geschrieben hat
Wenn Du sowas nicht machst dann haben die 300 User bisher in meinen Augen und meinen Erfahrungen nach großes Glück gehabt
nochmal ich greife DICH hier nicht an.. ich möchte dir nur aufzeigen dass das was du machst technisch nicht korrekt ist
-
Mich hat nach einem Stromausfall auch erwischt. Mein Master Slave-System will nicht mehr
Master Raspi3
Slave Raspi4
(Die Master/Slave Zuordnung war eigentlich umgekehrt geplant, hat sich aber so "ergeben")Ich habe mit dem Backups-Adapter aktuelle Backups auf meinem NAS (iobroker + javascripts) liegen.
Also kein großes Problem habe ich gehofft.Es sah nach einem Problem auf dem Master auf, da der Slave keine Verbindung bekam.
Habe daher auf dem Raspi3 ein "iobroker restore 0" durchgeführt, dabei wurde unbeabsichtigt eine lokale Version von vor einem Jahr benutzt, (bevor ich auf die NAS-Speicherung umgestellt habe). Es tat sich danach auch etwas, zumindest der admin-adapter lief.
Dann habe ich das aktuelle Backup von NAS in das Raspi3-Backup-Verzeichnis kopiert und wieder "ein iobroker restore 0" durchgeführt. Das lief auch durch. Ich konnte beide iobroker auf beiden Raspis starten und die haben sich wohl auch gefunden.
Es sind nun aber keine Instanzen per "iobroker list instances" sichtbar.
Auch ein "ps -A | grep iobroker" zeigt keine Ausgabe, obwohl der iobroker angeblich läuft.Ich habe jetzt Angst das ich das weiter verpfusche.
Wie kann ich das Backup sauber einspielen ?Raspi 4
pi@Raspi4:~ $ node -v v12.21.0 pi@Raspi4:~ $ npm -v 6.14.11 pi@Raspi4:~ $ iobroker -version 3.3.22 pi@Raspi4:iobroker status iobroker is running on this host. At least one iobroker host is running. Objects type: file States type: file pi@Raspi4:~ $ ps -A | grep iobroker pi@Raspi4:~ $ ls -lh /opt/iobroker/iobroker-data/backup-objects/ | grep objects .. -rw-rwxr--+ 1 iobroker iobroker 604K Mar 15 2021 2021-03-15_23-29_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 539K Mar 16 2021 2021-03-16_21-30_objects.json.gz pi@Raspi4:~ $ iobroker list instances + instance is alive pi@Raspi4:~ $Raspi 3
pi@Raspi3:/opt/iobroker $ node -v v12.20.1 pi@Raspi3:/opt/iobroker $ npm -v 6.14.10 pi@Raspi3:/opt/iobroker $ iobroker status iobroker is running on this host. Objects type: file States type: file pi@Raspi3:/opt/iobroker $ sudo iobroker list instances + instance is alive pi@Raspi3:/opt/iobroker $ ps -A | grep iobroker pi@Raspi3: pi@Raspi3:/opt/iobroker $ ls -lh /opt/iobroker/iobroker-data/backup-objects/ | grep objects -rw-rwxr--+ 1 iobroker iobroker 2.1M Mar 13 02:33 2022-03-13_02-33_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 2.1M Mar 13 04:34 2022-03-13_04-34_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 2.1M Mar 13 06:35 2022-03-13_06-34_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 2.1M Mar 13 08:35 2022-03-13_08-35_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 1.1K Mar 13 10:17 2022-03-13_10-17_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 1.1K Mar 13 10:18 2022-03-13_10-18_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 1.1K Mar 13 11:02 2022-03-13_11-02_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 1.2K Mar 13 11:03 2022-03-13_11-03_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 1.2K Mar 13 11:04 2022-03-13_11-04_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 1.2K Mar 13 11:05 2022-03-13_11-05_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 1.2K Mar 13 11:06 2022-03-13_11-06_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 1.2K Mar 13 11:07 2022-03-13_11-07_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 1.9K Mar 13 11:08 2022-03-13_11-08_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 1.9K Mar 13 11:09 2022-03-13_11-09_objects.json.gz .... -rw-rw-r--+ 1 iobroker iobroker 1.9K Mar 13 12:05 2022-03-13_12-05_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 27K Mar 13 12:06 2022-03-13_12-06_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1.8M Mar 13 12:16 2022-03-13_12-16_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1.8M Mar 13 12:22 2022-03-13_12-22_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1.4M Mar 13 12:28 2022-03-13_12-28_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1.4M Mar 13 12:44 2022-03-13_12-44_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1.4M Mar 13 12:45 2022-03-13_12-45_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1.4M Mar 13 12:48 2022-03-13_12-48_objects.json.gzUpdate: Im Raspi4 (Slave) Backup-Verzeichnis liegen die neuesten Backups, weil dort der Adapter läuft.
Dort kann das "iobroker restore 0" nicht starten.pi@Raspi4:~ $ iobroker restore 0 Stop iobroker first! pi@Raspi4:~ $ iobroker stop pi@Raspi4:~ $ iobroker restore 0 Stop iobroker first! ### => (iobroker auf Master gestoppt) pi@Raspi4:~ $ iobroker restore 0 No connection to databases possible ... pi@Raspi4:~ $ -
@tottbeck Jetzt mal gaaaanz langsam .....
Ein Slave hat faktisch keine eigenen Daten die ein Backup restoren kann ... der Master ist der EINZIGE mit einer DB. EIn Restore auf dem Slave hat keine Ahnung was angerichtet ...
Jetzt müssen wir erstmal rausfinden was bei Dir genau los ist!!
Also fangen wir mit dem Master an ... Es sieht ja so aus also ob du von der DB noch ein Objects-Backup hast von "Mar 13 12:16 2022-03-13_12-16_objects.json.gz" ,mit 1,8MB .... War das vor dem stromausfall? Dann wäre es viel einfacher gewesen einfach dieses File wiederherzustellen anstelle wilf ein Backup zu restoren ...
Hast Du auch noch ein states Backup dort von ungefähr gleicher zeit? Wenn ja. Master (und slave - den am besten eh gestoppt lassen!) stoppen. Dann die objects und states Backups entpacken und ersetzen. Dann Master starten und ins Log schauen ... passt da alles wieder??
Wenn das so ist .. Slave starten ... Dort Log schauen ... wie sieht es da aus?
Was natürlich jetzt sein kann durch deine restores das User-eigene Files von Visus oder so fehlen ... da musste schauen ...
-
@apollon77
Danke schonmal für die schnelle Reaktion.Ich habe das Backup schon auf dem Master(Raspi) gemacht. Das hat es dann aber eine lokale Version genommen, die ein Jahr alt ist.
Danach habe ich die Sicherung, die der BackitUp-Adapter (der läuft auf dem performanteren Slave-Raspi4 und legt da die lokalen Kopien ab, evtl ist das das Problem) auf meinem NAS ablegt, in den Raspi3 backup-Ordner kopiert und restored. Danach ging aber nichts mehr.Jetzt habe ich wieder den alten Backup eingespielt, das läuft prinzipiell, ist aber ein Jahr alt. Ich habe jetzt versucht ein Restore über den BackitUpAdatper zu machen. Der wird mir zwar als installiert angezeigt (Ver. 2.3.3), aber erscheint nicht unter Instanzen. Um eine neue Instanz kann ich nicht anlegen. (host.Raspi4 Invalid version of "admin". Installed "4.2.1", required ">=5.1.0", obwohl der Admin eigentlich Version 5.3.1 hat.
Der Stromausfall war um ca. 10:00, d.h. die 2.1M-Files waren wohl die vollständigen.
Ich habe nun die objects und states von 8:00 genommen. Damit startet er auch. Durch das alte Backup habe ich mir da aber jetzt etwas durcheinander gebracht.
Ich muss doch jetzt "nur" noch ein aktuelles Backup einspielen können. -
@tottbeck sagte in Mini-HowTo: Cannot find view "system" for search "host":
Invalid version of "admin". Installed "4.2.1", required ">=5.1.0",
Das wäre duerch ein "iob upload admin" gefixt gewesen
-
@apollon77 sagte in Mini-HowTo: Cannot find view "system" for search "host":
Das wäre duerch ein "iob upload admin" gefixt gewesen
OK, danke. Habe ich gemacht (auf dem Master) und konnte dann ein BackItUp Instanz anlegen (auf dem Slave wo sie vorher auch war).
Dann kann ich das lokale Backup auswählen, aber das Einspielen klappt nicht.
Die Meldung ist zwar etwas widerspüchlich, es geht aber etwas zu schnell und wurde wohl abgebrochen.
Wenn ich auf dem Master das BackItUp auswähle, (da findet er auch die auf dem Slave-Backup-Folder, dann kommt in dem Restore Fenster nur eine Fehlermeldung "192.168.xxx.yyy hat die Verbindung abgelehnt."Dann habe ich BackItUp auf der Raspi3 (Master) verschoben, das Backup in den lokale Ordner kopiert und restored.
Das geht zwar aber dann habe ich wieder keine Instanzen. -
@tottbeck das dauert.
Hast du mal parallel ins iobroker log geschaut bzw. Wie lange hast du gewartet?
-
@tottbeck dann am Besten mal im
Backitup thread melden? -
@wendy2702
Ich habe nicht auf den log geschaut, aber mindesten 30 Minuten gewartet.
Mit dem alten Backup hatte ich schon nach kurzer Zeit wieder die ersten Instanzen up.Ich habe iwie keine Möglichkeit gefunden das Backup vernünftig einzuspielen.
Ist es nicht zulässig ein BackitUp-Restore vom Slave zu machen? (Hatte ich mal gemacht meine ich bin aber nicht sicher)@apollon77
Ja macht wohl mehr Sinn bzgl BackitUp, ich hänge das mal an meinen alten Thread zum Multihost
https://forum.iobroker.net/topic/43295/slave-adapter-fehlen-beim-multihost-system-aufsetzen/11Danke Euch
-
@apollon77 This situation happens to me every time when the container is reloaded. I'm already tired of restoring from a backup file. For me the procedure looks like this:
reloading the container, I get:
Cannot read system.config: null (OK when migrating or restoring)
npm i iobroker.js-controller@4.0.23 --production
iob stop
iob restore iobroker_2022_05_05-02_00_10_backupiobroker.tar.gz
and the agonizing wait until everything is removed and re-installed. Is there a way to fix it faster? I tried the fix, it doesn't help.
also found that when this happens the iobroker.json file resets the objects setting to "file" even though I'm using JSONL. I thought it would be better when I switched to it, but it only got worse. Please help, I'm really tired of restoring the entire system every time. -
@anzic What exactly do you mean with "when container is reloaded"?
Additionally: what does "iob status" give you ? Which DB type do you use? It should also not really happen with JSONL (which is starndard in 4.0.x contoller) and should also not happen again with js-controller 4 File DB usage.
So please provide logs from iobroker from such a "reload" last mins before and some mins after start". I hope that "reload" do not mean "immediate kill of anything and no proper shutdown"
-
@apollon77
i mean that when i restart container with iobroker (buanet/iobroker:v6.1.0). The iobroker.json file is reset to the default one, which states that the "file" object base is used instead of "jsonl". At this point, the controller tries to connect to the objects.json file which is generated automatically, which is 23 KB in size. And if I try to set up iobroker with iobroker setup custom specifying the correct "jsonl" as objects db (even if I put the previously saved objects.jsonl file in a folder), it overwrites it using the objects.json.migrated source file and the system doesn't start. So far I have found such a solution for recovery :
stop iobroker - iob stop
then I execute pgrep -f '^io.' | xargs kill -9 because not all processes are stopped, and if I don't do this and try to put the correct iobroker.json and objects.jsonl, the system will still overwrite them from the "wrong" objects.json.migrated. Therefore pgrep -f '^io.' | xargs kill -9
after that I replace the iobroker.json file and objects.jsonl that I saved on the working system.
and run iob start
in this order the system starts up. Unfortunately, I have to go to the slave later, and run iob setup custom , i.e. for some reason, he also loses contact with the master.root@iobroker:/opt/iobroker# iob isrun Cannot read system.config: null (OK when migrating or restoring) iobroker is running on this host. Objects type: file States type: redisReboot occurs by restarting the container, not power loss.
"Last entries" before rebooting do not give anything, there are standard logs that are not related to stopping the controller in any way.
But the first start can be interesting, apparently, the controller cannot find the objects.json file (although why is it looking for it if it should use objects.jsonl). This is probably due to the fact that after a reboot, an entry appears in the iobroker.json file that it is working with the "file", so it tries to "find" it.2022-05-11 22:48:04.387 - [32minfo[39m: host.iobroker iobroker.js-controller version 4.0.23 js-controller starting 2022-05-11 22:48:04.391 - [32minfo[39m: host.iobroker Copyright (c) 2014-2022 bluefox, 2014 hobbyquaker 2022-05-11 22:48:04.391 - [32minfo[39m: host.iobroker hostname: iobroker, node: v14.19.2 2022-05-11 22:48:04.391 - [32minfo[39m: host.iobroker ip addresses: 192.168.1.100 172.23.0.100 2022-05-11 22:48:04.402 - [33mwarn[39m: host.iobroker-Server Configured backup period 120 is larger than the supported maximum of 35791 minutes. Defaulting to 120 minutes. 2022-05-11 22:48:04.406 - [31merror[39m: host.iobroker-Server Cannot load /opt/iobroker/iobroker-data/objects.json: Database file /opt/iobroker/iobroker-data/objects.json does not exists.. We try last Backup! 2022-05-11 22:48:04.410 - [31merror[39m: host.iobroker-Server Cannot load /opt/iobroker/iobroker-data/objects.json.bak: Database file /opt/iobroker/iobroker-data/objects.json.bak does not exists.. Continue with empty dataset! 2022-05-11 22:48:04.410 - [31merror[39m: host.iobroker-Server If this is no Migration or initial start please restore the last backup from /opt/iobroker/iobroker-data/backup-objects 2022-05-11 22:48:04.500 - [31merror[39m: host.iobroker Cannot read system.config: null (OK when migrating or restoring) 2022-05-11 22:48:04.548 - [31merror[39m: host.iobroker Cannot find view "system" for search "host" 2022-05-11 22:48:04.589 - [32minfo[39m: host.iobroker connected to Objects and States 2022-05-11 22:48:04.618 - [32minfo[39m: host.iobroker added notifications configuration of host 2022-05-11 22:48:04.621 - [33mwarn[39m: host.iobroker logger system.adapter.admin.0.logging was deleted 2022-05-11 22:48:04.622 - [33mwarn[39m: host.iobroker logger system.adapter.javascript.2.logging was deleted 2022-05-11 22:48:04.623 - [33mwarn[39m: host.iobroker logger system.adapter.javascript.0.logging was deleted 2022-05-11 22:48:04.623 - [33mwarn[39m: host.iobroker logger system.adapter.iot.0.logging was deleted 2022-05-11 22:48:04.664 - [31merror[39m: host.iobroker Cannot find view "system" for search "instance" 2022-05-11 22:48:04.664 - [31merror[39m: host.iobroker Could not add notifications config of this host: Could not get notifications setup from instances: Cannot find view "system" 2022-05-11 22:48:04.677 - [32minfo[39m: host.iobroker Plugin sentry Sentry Plugin disabled for this process because sending of statistic data is disabled for the system 2022-05-11 22:48:04.682 - [31merror[39m: host.iobroker Cannot find view "system" for search "host" 2022-05-11 22:48:04.689 - [31merror[39m: host.iobroker Cannot find view "system" for search "state" 2022-05-11 22:48:04.689 - [31merror[39m: host.iobroker Cannot find view "system" for search "instance" 2022-05-11 22:48:04.690 - [31merror[39m: host.iobroker Could not collect system.host.iobroker states to check for obsolete states: Error: Cannot find view "system" 2022-05-11 22:48:04.690 - [31merror[39m: host.iobroker _design/system missing - call node iobroker.js setup 2022-05-11 22:48:04.691 - [32minfo[39m: host.iobroker no instances found 2022-05-11 22:48:04.691 - [32minfo[39m: host.iobroker no instances foundPerhaps in my case, it will be correct to make a "reverse" migration to "file" and then back to jsonl. Then the "correct" iobroker.json file will be created and at the next reboot, it will simply start using it, which of course is also not entirely true, but at least it will not "break" the whole system, I hope.
-
@anzic the main question is why the objects.json is not existing. It is not broken. It is not existing. So why???
Please show the content of /opt/iobroker/iobroker-data while running and ideally directly on such a restart.
Please also show „iob status“ from a running system
-
PS: What the variables are set in your container? e.g. IOB_STATESDB_TYPE .. if this is set to "file" then the DB will be reset on any start ... you then needs to adjust that to jsonl
-
Пользователь @apollon77 написал в Mini-HowTo: Cannot find view "system" for search "host":
IOB_STATESDB_TYPE
How did I miss this?? Indeed, "file" was written in docker-compose.yml. I'll change it to jsonl and check again. Thanks for the hint.
-
@apollon77 from nas:
Anzor@NAS:/volume2/doker_mapping/iobroker/iobroker-data$ ls -la total 26416 drwxrwxr-x 1 Anzor users 626 May 12 09:36 . drwxrwxr-x 1 Anzor users 764 May 11 22:47 .. drwxr-xr-x 1 Anzor users 64 Apr 15 01:12 backitup drwxrwxr-x 1 Anzor users 1840 May 12 11:03 backup-objects drwxr-xr-x 1 Anzor users 660 Feb 27 21:41 esphome.0 drwxrwxr-x 1 Anzor users 4128 May 11 02:07 files drwxrwxrwx 1 Anzor users 58 Mar 27 13:15 ham_0 drwxr-xr-x 1 Anzor users 0 Oct 31 2021 homekit-controller.0 -rw-rwxr-- 1 Anzor users 3593 May 11 23:18 iobroker.json drwxr-xr-x 1 Anzor users 0 Jun 30 2020 letsencrypt drwxrwxrwx 1 Anzor users 22 Jun 30 2020 lgtv_0 drwxr-xr-x 1 Anzor users 22 Jul 10 2020 lgtv_1 drwxrwxrwx 1 Anzor users 24 Jun 30 2020 mercury_0 drwxrwxrwx 1 Anzor users 200 May 10 23:08 my-backup drwxr-xr-x 1 Anzor users 714 May 8 11:35 node-red -rw-rw-rw- 1 Anzor users 3 May 11 02:09 notifications.json -rw-r--r-- 1 Anzor 1000 23624 May 11 22:48 objects.json.bak.migrated -rw-rw-rw- 1 Anzor 1000 26957147 May 12 11:40 objects.jsonl -rw-rw-rw- 1 Anzor users 12762 May 11 01:57 objects.jsonl.444 -rw-rw-rw- 1 Anzor users 12762 May 11 02:01 objects.jsonl.gj drwxrwxrwx 1 Anzor 1000 0 May 12 11:40 objects.jsonl.lock -rw-r--r-- 1 Anzor 1000 23624 May 11 22:58 objects.json.migrated drwxr-xr-x 1 Anzor users 60 Aug 6 2020 sayit drwxrwxrwx 1 Anzor users 0 Apr 24 02:01 telegram_0 drwxrwxrwx 1 Anzor users 32 Sep 11 2021 tmp drwxr-xr-x 1 Anzor users 18 Sep 14 2020 tuya_0 drwxrwxrwx 1 Anzor users 640 May 7 00:19 yahka.0.hapdata drwxr-xr-x 1 Anzor users 128 May 2 2021 yahka.1.hapdata drwxr-xr-x 1 Anzor users 22 Jun 30 2020 zigbee_0 Anzor@NAS:/volume2/doker_mapping/iobroker/iobroker-data$from inside of container:
root@iobroker:/opt/iobroker/iobroker-data# ls -la total 26448 drwxrwxr-x 1 iobroker users 626 May 12 09:36 . drwxrwxr-x 1 iobroker users 764 May 11 22:47 .. drwxr-xr-x 1 iobroker users 64 Apr 15 01:12 backitup drwxrwxr-x 1 iobroker users 1840 May 12 11:03 backup-objects drwxr-xr-x 1 iobroker users 660 Feb 27 21:41 esphome.0 drwxrwxr-x 1 iobroker users 4128 May 11 02:07 files drwxrwxrwx 1 iobroker users 58 Mar 27 13:15 ham_0 drwxr-xr-x 1 iobroker users 0 Oct 31 2021 homekit-controller.0 -rw-rwxr-- 1 iobroker users 3593 May 11 23:18 iobroker.json drwxr-xr-x 1 iobroker users 0 Jun 30 2020 letsencrypt drwxrwxrwx 1 iobroker users 22 Jun 30 2020 lgtv_0 drwxr-xr-x 1 iobroker users 22 Jul 10 2020 lgtv_1 drwxrwxrwx 1 iobroker users 24 Jun 30 2020 mercury_0 drwxrwxrwx 1 iobroker users 200 May 10 23:08 my-backup drwxr-xr-x 1 iobroker users 714 May 8 11:35 node-red -rw-rw-rw- 1 iobroker users 3 May 11 02:09 notifications.json -rw-r--r-- 1 iobroker iobroker 23624 May 11 22:48 objects.json.bak.migrated -rw-rw-rw- 1 iobroker iobroker 26992013 May 12 11:41 objects.jsonl -rw-rw-rw- 1 iobroker users 12762 May 11 01:57 objects.jsonl.444 -rw-rw-rw- 1 iobroker users 12762 May 11 02:01 objects.jsonl.gj drwxrwxrwx 1 iobroker iobroker 0 May 12 11:42 objects.jsonl.lock -rw-r--r-- 1 iobroker iobroker 23624 May 11 22:58 objects.json.migrated drwxr-xr-x 1 iobroker users 60 Aug 6 2020 sayit drwxrwxrwx 1 iobroker users 0 Apr 24 02:01 telegram_0 drwxrwxrwx 1 iobroker users 32 Sep 11 2021 tmp drwxr-xr-x 1 iobroker users 18 Sep 14 2020 tuya_0 drwxrwxrwx 1 iobroker users 640 May 7 00:19 yahka.0.hapdata drwxr-xr-x 1 iobroker users 128 May 2 2021 yahka.1.hapdata drwxr-xr-x 1 iobroker users 22 Jun 30 2020 zigbee_0 root@iobroker:/opt/iobroker/iobroker-data#root@iobroker:/opt/iobroker/iobroker-data# iob status iobroker is running on this host. Objects type: jsonl States type: redis root@iobroker:/opt/iobroker/iobroker-data#
