Mit dem Schritt von TrueNAS Scale 24.04 auf 24.10, den "Eletric Eel" wurde die Grundlage für die "Apps" geändert von Kubernetes auf Docker. Vor allem, wenn man ein Update einspielt oder eine neue App installiert, merkt man doch einen deutlichen Geschwindigkeitsunterschied.
Ich wollte letzte Woche jetzt den Vaultwarden-Server als App installieren. Man findet auch schnell die Dokumentation dazu: Documentation Hub/TrueNAS Apps/Community Apps/Vaultwarden. Und natürlich gibt es auch weitere Blog-Artikel, Foren-Einträge usw. Aber das allermeiste bezieht sich noch auf TrueNAS Scale-Versionen vor 24.10, wie es bei einer ganz neuen Version auch zu erwarten ist.
Ich habe die App einfach mal installiert, natürlich mit einem Host Path für den Vaultwarden Data Storage und den Vaultwarden Postgres Data Storage, aber ansonsten den Vorgabewerten. Leider scheitert die Installation mit "[EFAULT] Failed 'up' action for 'vaultwarden' app, please check /var/log/app_lifecycle.log for more details". Das erwähnte Protokoll lieferte aber keine nützlichen Informationen.
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/middlewared/job.py", line 488, in run
await self.future
File "/usr/lib/python3/dist-packages/middlewared/job.py", line 535, in __run_body
rv = await self.middleware.run_in_thread(self.method, *args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/middlewared/main.py", line 1364, 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 1361, 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/service/crud_service.py", line 268, in nf
rv = func(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/middlewared/schema/processor.py", line 55, in nf
res = f(*args, **kwargs)
^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/middlewared/schema/processor.py", line 183, in nf
return func(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/middlewared/plugins/apps/crud.py", line 203, in do_create
return self.create_internal(job, app_name, version, data['values'], complete_app_details)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/middlewared/plugins/apps/crud.py", line 248, in create_internal
raise e from None
File "/usr/lib/python3/dist-packages/middlewared/plugins/apps/crud.py", line 241, in create_internal
compose_action(app_name, version, 'up', force_recreate=True, remove_orphans=True)
File "/usr/lib/python3/dist-packages/middlewared/plugins/apps/compose_utils.py", line 57, in compose_action
raise CallError(
middlewared.service_exception.CallError: [EFAULT] Failed 'up' action for 'vaultwarden' app, please check /var/log/app_lifecycle.log for more detailsIm Rahmen verschiedener Installationsversuche habe ich es dann mal ohne "richtige" Host Pathes versucht, einfach mit ixVolumes. Und da lief die Installation durch?!
Zu der App gehören drei Container, wovon einer "permissions" wohl nur einmalig und temporär gestartet wird, um die Berechtigungen für die Data Storages zu setzen. Das Protokoll dieses Containers enthielt dann das, was mich entscheidend weiter gebracht hat:
2024-11-23 16:03:52.419179+00:00=== Applying configuration on volume with identifier [postgres_postgres_data] ===
2024-11-23 16:03:52.419300+00:00Current Ownership and Permissions on [/mnt/permission/postgres_postgres_data]:
2024-11-23 16:03:52.419333+00:00Ownership: wanted [999:999], got [0:0].
2024-11-23 16:03:52.419358+00:00Permissions: wanted [None], got [0755].
2024-11-23 16:03:52.419397+00:00---
2024-11-23 16:03:52.419421+00:00Ownership is incorrect. Fixing...
2024-11-23 16:03:52.419444+00:00Changing ownership to 999:999 on: [/mnt/permission/postgres_postgres_data]
2024-11-23 16:03:52.419466+00:00Ownership after changes:
2024-11-23 16:03:52.419489+00:00Ownership: [999:999]
...
2024-11-23 16:03:52.419615+00:00=== Applying configuration on volume with identifier [data] ===
2024-11-23 16:03:52.419650+00:00Current Ownership and Permissions on [/mnt/permission/data]:
2024-11-23 16:03:52.419675+00:00Ownership: wanted [568:568], got [0:0].
2024-11-23 16:03:52.419697+00:00Permissions: wanted [None], got [0755].
2024-11-23 16:03:52.419720+00:00---
2024-11-23 16:03:52.419741+00:00Ownership is incorrect. Fixing...
2024-11-23 16:03:52.419774+00:00Changing ownership to 568:568 on: [/mnt/permission/data]
2024-11-23 16:03:52.419799+00:00Ownership after changes:
2024-11-23 16:03:52.419821+00:00Ownership: [568:568]
...568 ist die ID des Standard-Benutzers und der Standard-Gruppe für apps. 999 ist die ID des Benutzers 'netdata' bzw. die ID der Gruppe 'docker'. Und offensichtlich müssen dieser Benutzer und diese Gruppe Eigentümer der Dateien unter dem konfigurierten Host Path für den Postgres Data Storage sein. Der permissions-Container hat leider nicht genügend Rechte, um die Berechtigungen entsprechend einzustellen. Also muss das manuell passieren.
Kaum habe ich die Eigentümer für das Dataset, das ich als Host Path für den Vaultwarden Postgres Data Storage verwende, entsprechend auf netdata:docker [999:999] umgestellt, läuft auch die Installation der App mit Host Pathes erfolgreich durch.
