TrueNAS Cron / Docker

Moin liebe Community,

ich versuche einen Cron-Job in TrueNAS einzurichten.

Dazu wurde ein Shellscript mit folgendem Inhalt erstellt:


#!/bin/bash

docker exec nextcloud php /var/www/html/cron.php


Führe ich nun den Job aus, erhalte ich folgende Meldung:


[EFAULT] CronTask “path/nextcloud-cron.sh > /dev/null” exited with 1 (non-zero) exit status.

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/middlewared/api/base/server/ws_handler/rpc.py", line 361, in process_method_call
    result = await method.call(app, id_, params)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/middlewared/api/base/server/method.py", line 63, in call
    result = await result.wait(raise_error=True, raise_error_forward_classes=(Exception,))
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/middlewared/job.py", line 475, in wait
    raise self.exc_info[1]
  File "/usr/lib/python3/dist-packages/middlewared/job.py", line 527, in run
    await self.future
  File "/usr/lib/python3/dist-packages/middlewared/job.py", line 574, in __run_body
    rv = await self.middleware.run_in_thread(self.method, *args)
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/middlewared/main.py", line 670, in run_in_thread
    return await self.run_in_executor(io_thread_pool_executor, method, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/middlewared/main.py", line 667, in run_in_executor
    return await loop.run_in_executor(pool, functools.partial(method, *args, **kwargs))
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/concurrent/futures/thread.py", line 58, in run
    result = self.fn(*self.args, **self.kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/middlewared/api/base/decorator.py", line 116, in wrapped
    result = func(*args)
             ^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/middlewared/plugins/cron.py", line 253, in run
    raise CallError(f'CronTask "{cron_cmd}" exited with {cp.returncode} (non-zero) exit status.')
middlewared.service_exception.CallError: [EFAULT] CronTask "/mnt/DATA/User/truenas/bin/nextcloud-cron.sh > /dev/null" exited with 1 (non-zero) exit status.

Als Mail erhalte ich:

The command:

docker exec nextcloud php /var/www/html/cron.php

Produced the following output:

permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.51/containers/nextcloud/json": dial unix /var/run/docker.sock: connect: permission denied

If you don’t wish to receive these e-mails, please go to your Cron Job options and check “Hide Standard Output” and “Hide Standard Error” checkboxes.


Das Ausführen des Scriptes in der Shell funktioniert einwandfrei …

Hat jemand eine Idee ?

LG

Führst du den Cronjob als root aus?

Ja, der wird als “root” ausgeführt.

Habe hier auch andere Scripte laufen wie z.B. Shutdown, Reboot und Docker, die ohne Fehler ausgeführt werden.

Nur dieses “neue Script” mit exec macht Probleme.

Mir ist aber gerade eingefallen, dass ich kurz vorher auf 26.10.4 gegangen bin … Muss mal die anderen Scripte testen und ob diese noch laufen.

LG

Ja, die anderen Scripte laufen. docker stop / start funktioniert ebenfalls problemlos. Sieht so aus, als würde hier lediglich der Aufruf “exec” Probleme machen …

bist du dir 100% sicher dass der container “nextcloud” heisst? truenas apps heissen normal irgendwas mit ix-appname

Nach kurzer Recherche besteht das Problem wohl ab 25.10.x …

Der einschlägige Tipp war, einen “user” zu erstellen und zur Gruppe “docker” hinzuzufügen.

Also einen user “docker_cronjob” erstellt und diesen unter der “primary group” in “docker” erstellt.

Danach den user noch zur Gruppe der “builtin_administrators” hinzugefügt und den cron job angepasst …

Ergebnis : permission denied

Mal ehrlich und Hand aufs Herz … Wo soll dieser geisteskranke Rechteentzug und / oder Verschlüsselung noch hinführen, wenn am Ende nichts mehr funktioniert und die Recherche die 3-fache Zeit in Anspruch nimmt, als die eigentliche Installation / Konfiguration / Administration ?

OpenSource und die Community wird langsam von paranoiden Idioten unterwandert und liegt im sterben …

LG

Ja, das bin ich …

Vielleicht hätte ich zusätzlich erwähnen sollen …

  1. Dockhand als ix-app eingerichtet wurde
  2. Alle zusätzlichen Apps unter Dockhand eingerichtet werden

Sollte aber mit dem eigentlichen Problem nichts zu tun haben, da andere Scripte für die Container ja auch laufen.

LG

So, das Problem wurde “kurzfristig” behoben …

Ein Änderung der Rechte brachte das Script zur Ausführung. Bis zum nächsten Update :smile:


ls -l /var/run/docker.sock
srw-rw---- 1 root docker 0 Jun 12 12:51 /var/run/docker.sock

sudo chmod 666 /var/run/docker.sock

ls -l /var/run/docker.sock
srw-rw-rw- 1 root docker 0 Jun 12 12:51 /var/run/docker.sock


Das Ganze muss nur bei Neustart erneut ausgeführt oder in einem Script umgesetzt werden …

Sollte das beim nächsten Update wieder “eingeschränkt” werden, bin ich raus aus TrueNAS und sehe mich anderweitig um. Leider hat ZimaOS andere Probleme wie “Legacy Container” auf der Weboberfläche und keinen funktionieren Cron.

LG

Edit

Eine Ausführung über “Init/Shutdown Scripts” funktioniert “erstmal” problemlos …

@RGB Was ich noch nicht ganz nachvollziehen kann: Du hast Skripte, die beim Start und Herunterfahren ausgeführt werden - wofür genau brauchst du die? Mein NAS läuft gefühlt 24/7 durch, dafür ist es ja auch ausgelegt und konzipiert.
Wenn dir TrueNAS als NAS‑Appliance nicht zusagt und ZimaOS auch nicht, warum baust du dir dann nicht einfach selbst ein System auf Basis einer Linux‑Distribution deiner Wahl? Dann kannst du alles genau so umsetzen, wie es für deine Anforderungen passt.

@micneu

Das ist hier nicht ganz so einfach zu erklären … Nur kurz :

  1. Ist das Ganze noch eine Testumgebung. Ich kann mich jederzeit für etwas anderes entscheiden. Ich hatte mich zuerst mit Docker Desktop und WSL beschäftigt, das dann aber wieder verworfen.
  2. Habe ich keine Lust auf Frickelkram. Ich brauche ein zuverlässiges System, welches nicht bei jedem Update etwas ändert, ggfs. nichts mehr funktioniert oder bei Fehlern erstmal eine stundenlange Suche erfolgen muss, weil keiner Plan hat. Des Weiteren muss ich meine pers. Anforderungen umsetzen können ohne dabei immer das System verbiegen zu müssen.
  3. Ist die Umsetzung nicht als Kellerserver gedacht, sondern eine Umstrukturierung in unserem Betrieb. Der Betrieb trennt sich und dabei trennen sich ebenfalls Daten, Netz, usw. und es kommen andere Dinge wie z.B. Apps (Paperless, etc.) hinzu, weil es gerade “in” ist.
  4. Läuft TrueNAS nicht als reale Maschine, sondern zusammen mit einer anderen TrueNAS-Umgebung und 2 Windows-Maschinen in Hyper-V. Diese werden z.B. ab xx:xx Uhr heruntergefahren und gesichert.

LG

Nachtrag:

Ich habe bis 09/2026 Zeit ein laufendes System nach den gegebenen Anforderungen auf die Beine zu stellen. Dazu teste ich alles in Frage kommende inkl. Abstürze, Stromausfall, Crash der Platten, Datenverlust / Wiederherstellung und Administrierfreundlichkeit. Da ich aus einem sehr zuverlässigen System komme welches seit 2010 (Betriebsgründung) absolut ohne Ausfälle läuft, möchte ich das Neue System natürlich ebenfalls so umsetzen.

Zwei Dinge fallen mir bei deinen Anforderungen/Wünschen auf:

paperless:

Eine feine Sache, habe ich selbst auch privat. Aber meines Wissens ist paperless nicht revisionssicher. Ich weiss nicht, ob das im betrieblichen Umfeld Pflicht ist.

Virtualisierung von TN:

Das Thema hier im Forum bereits vielfach durchgekaut und vermutlich hast du es auch gelesen. TN braucht komplett Pass-Trough (schreibt man das so?) durchgereichte Kontroller/Ports für die Platten. Alles andere führt dich früher oder später in die Katastrophe. Wenn du also zumindest die Speichersystem langfristig stabil betreiben willst, denke ernsthaft über TN direkt auf dem Eisen nach. Und warum willst du TN über das Hostsystem sichern? TN hat eigene robuste Mechanismen.

Abgesehen davon kannst du auch auf TN gut Virtualisieren.

Und was die Rechteänderung betrifft - solange du nicht nach jedem Update zusätzlich den Schreibschutz vom Root-Dateisystem nehmen musst, dürfte ein Script beim Starten unproblematisch sein. Das funktioniert eigentlich alles reibungslos, wenn einmal sauber am Laufen.

1 Like

@VeitS

Die Umstellung, bei z.B. Paperless, betrifft nur den Zugriff vom Café oder Strand aus. Einigen im Betrieb ist der jetzige Zugriff auf Daten / Dokumente über 1. VPN-Einwahl 2. Anmeldung über RDP zu umständlich.

Die eigentliche Unternehmensanwendung hat keine Webfunktionen und wird sie auf Nachfrage auch nicht bekommen. Ein anderer Punkt ist, diese Anwendung ist komplett abhängig von MS Office in lokal installierter Vetsion. Aus diesem Grund soll eine komplett neue Anwendung an einen Softwareentwickler gegeben werden, obwohl es ca. 20 andere Cloudanwendungen gäbe …

TN läuft aus dem einfachsten aller Gründe nicht als Hostsystem / Hypervisor … Alles läuft unter MS bestens und TN wird eigentlich nur für Docker gebraucht. TN mit seinem Zwang zu ZFS empfinde ich persönlich als Zumutung und jetzt frage bitte nicht warum … für mich spielt ein unkomplizierter Zugriff eine Rolle, der ist hier nicht gegeben.

TN hat derzeit als System 10GB … wer sich schon mal mit Sicherungen auseinander gesetzt hat wird festgestellt haben, dass eine große Datei schneller gesichert ist, als viele kleine Dateien. Und da wir ca. 2 Millionen kleine Dateien bewegen, dauert so eine Sicherung schon ziemlich übel lange …

Keine Ahnung ob ich wad vergessen habe, schreibe gerade vom Phone …

LG

Paperless (ppl) bietet nur den Zugriff mittels HTTP. Das ist also etwas, was du bestenfalls mit einem entsprechend vorgesetzten Proxi ins Internet stellen willst. Oder alternativ VPN. Privat nutze ich Wireguard, das geht sehr bequem.

TN selbst als System musst du nicht wirklich sichern. Wenn da das Bootlaufwerk hop geht, spielst du ein frisches Installationsimage auf und liest anschließend die (hoffentlich separat vorhandene!) Sicherung der Konfiguration wieder ein. Das erledigst du locker in einer 1/2 Stunde.

ZFS sehe ich persönlich nicht als Zumutung und ich denke auch kein anderer TN-Nutzer. Wenn du dir die Mühe machst etwas über ZFS zu lesen, wirst du schnell feststellen, das ZFS mit seinen Features recht wenig Konkurrenz hat. Unter Linux vielleicht noch BTRFS. Da kenne ich mich leider zu wenig aus. Aber die Entwickler von IX-Systems haben sich beim Umstieg von BSD auf Linux sicher etwas dabei gedacht, bei ZFS zu bleiben anstatt nach bspw. BTRFS zu wechseln (ich denke, Bequemlichkeit wird nicht der wesentliche Aspekt gewesen sein;).

Was die Sicherung betrifft, hast du recht was viele kleine Dateien angeht. Aber eben da spielt ZFS seine Stärken aus. Wenn du die Daten auf ein 2. TN-System replizierst, kannst du mit Schnappschüssen arbeiten und nur die dann ebenfalls wieder auf das Backup-System übertragen. Und von dem Backup-System kannst du in aller Seelenruhe auf was auch immer wegsichern.

Wenn du TN aber nur wegen Docker haben willst, nimm eher ein Linux oder BSD mit ZFS. Da dürftest du vermutlich schneller an dein Ziel gelangen.

1 Like

Da würde ich dann aber eher auf ubuntu server oder debian gehen, weil mir die docker implementierung auf truenas zu restriktiv wäre/ist.

1 Like

@VeitS

VPN wird ja schon genutzt und wird wohl auf WG umgestellt. Ich hoffe, dass WG nicht so anfällig für Änderungen / Updates ist und sich ein Client auf aufgrund geänderter Anforderungen seitens der Entwickler nicht mehr einwählen kann …

Keine Sorge, nichts wird öffentlich ins Netz gestellt oder irgendwelche Ports nach außen geöffnet. Nginx habe ich trotzdem mal testweise für das Intranet installiert (Nextcloud, Vaultwarden) und mit “korrekter” OpenSSL CA und Serverzertifikaten gefüttert … Läuft bisher einwandfrei und ohne Sicherheitswarnung in den Browsern.

Ansonsten … alle Wege führen zur Bundesregierung … sorry Rom.

LG

Die Bedenken hatte ich auch, mit Dockhand als ix-app und den Rest unter Dockhand läuft auch hier bisher alles. Darunter Paperless, Nextcloud, Vaultwarden, Homarr, Mailarchiver, Collabora, Beszel, Nginx, Immich, SFTPGo …

LG

Darf ich fragen, in welchem Bereich euer Unternehmen tätig ist? Ich wundere mich etwas, dass in einem Betriebsumfeld eine Lösung wie Immich benötigt wird.
Für diesen Einsatzzweck würde ich persönlich eher auf TrueNAS verzichten und stattdessen einen Linux‑Server mit einer Distribution deiner Wahl in Kombination mit Podman und Portainer einsetzen.

Natürlich … Immobilien

Wie oben schon erwähnt,

  1. ist das erstmal eine Testumgebung
  2. wird das nur gebraucht, um mal schnell im Cafe auf etwas zuzugreifen. Eine “eigene” Cloudanwendungen soll Mitte 2027 am Start sein.
  3. muss Immich nicht das Richtige sein, habe bis jetzt keine Alternative. Aber mit Geo und KI finde ich das schon durchaus interessant.

LG

Ich bin mal deinem Rat gefolgt und habe Ubuntu getestet …

Nur bekomme ich hier auch wieder so ein kleine “Krise”, da sich Docker nicht nach Anleitung starten lässt. Hier ist wohl das Problem “AppAmor” und man muß wieder überall herumfrickeln …

Gibt es in der Konsolenwelt eigentlich “nur” ein einziges System, welches sich ohne Riesengefrickel und Aufwand betreiben lässt ? Also sowas wie unter dem “bösen” Windows, System installieren, App installieren, läuft ? :heart:

Und nein, ich habe keine Berührungsängste mit der Konsole, allerdings ist das unter diesem “tollen” System schon ein wenig krankhaft …

LG

Auf Ubuntu Server ist per Default kein AppArmor aktiv.