Cloudron Forum

thanks, one of my instances seemed to be effected by this

Hi James, Here are all the details I have so far. Cloudron environment: Vendor: QEMU Product: Standard PC Linux: 6.8.0-111-generic Ubuntu: noble 24.04 Cloudron: 9.1.7 Execution environment: kvm Processor: AMD EPYC 9354P 32-Core Processor BIOS: pc-i440fx-11.0 RAM: 8131480KB Disk: /dev/sda1 53G Output of cloudron-support --troubleshoot: [OK] node version is correct [OK] IPv6 is enabled and public IPv6 address is working Docker is down. Trying to restart docker... Job for docker.service failed because the control process exited with error code. See "systemctl status docker.service" and "journalctl -xeu docker.service" for details. Output of systemctl status docker.service: docker.service - Docker Application Container Engine Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; preset: enabled) Drop-In: /etc/systemd/system/docker.service.d/cloudron.conf Active: failed (Result: exit-code) since Wed 2026-05-20 06:24:24 UTC; 3 days ago TriggeredBy: docker.socket Main PID: 1480807 (code=exited, status=1/FAILURE) docker.service: Scheduled restart job, restart counter is at 3. docker.service: Start request repeated too quickly. docker.service: Failed with result 'exit-code'. Failed to start docker.service - Docker Application Container Engine. Output of journalctl -xeu docker.service: dockerd[1480807]: unable to configure the Docker daemon with file /etc/docker/daemon.json: the following directives are specified both as a flag and in the configuration file: log-driver: (from flag: journald, from file: json-file) docker.service: Main process exited, code=exited, status=1/FAILURE docker.service: Failed with result 'exit-code'. Failed to start docker.service - Docker Application Container Engine. docker.service: Start request repeated too quickly. So Docker cannot start because log-driver seems to be defined twice: as a systemd flag: journald in /etc/docker/daemon.json: json-file Cloudron is already on 9.1.7, but Docker is down. What is the safest Cloudron-compatible fix here without data loss? Should I remove the log-driver entry from /etc/docker/daemon.json, or should the Cloudron systemd override be changed? Thanks.

@james said: With the Dry run restore when taking this path you can also ensure that everything is working as intended reducing possible downtimes. Exactly

Hello @luckow Thanks for providing the logs. You have peertube-plugin-tv-streaming installed, which declares a git-resolved transitive dep that pnpm v11 rejects: [ERR_PNPM_EXOTIC_SUBDEP] Exotic dependency "@silvermine/videojs-chromecast" (resolved via git-repository) is not allowed in subdependencies when blockExoticSubdeps is enabled This error happened while installing the dependencies of peertube-plugin-tv-streaming@1.2.1 PeerTube 8.1.6 ships pnpm v11, which defaults blockExoticSubdeps to true. v10 didn't. I reproduced your issue with installing the PeerTube package version 4.6.6, installing the peertube-plugin-tv-streaming and updating to version 4.6.7. It looks like this is an upstream issue with pnpm https://github.com/pnpm/pnpm/issues/11799 with a suggested solution that is yet to be implemented https://github.com/pnpm/pnpm/pull/11805#issuecomment-4507912313 This issue can be resolved manually by editing or creating the file in /app/data/storage/plugins/pnpm-workspace.yaml with the following content: dangerouslyAllowAllBuilds: true nodeLinker: hoisted blockExoticSubdeps: false But this leads to the next issue that the installation of a plugin is waiting for a key to be confirmed: [peer.cloudron.dev:443] 2026-05-23 10:38:01.027 info: Installing plugin peertube-plugin-auth-openid-connect. The authenticity of host 'github.com (140.82.121.3)' can't be established. ED25519 key fingerprint is SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU. This key is not known by any other names. Are you sure you want to continue connecting (yes/no/[fingerprint])? So we need to prevent this as well. I will look into resolving this issue with an app update.

Hello @superhua Currently, the @grist app for Cloudron does not come with the enterprise option. We will need to look into that again, see https://forum.cloudron.io/post/124882

@marcusquinn what can i say it's in the never ending list of platform features to add.

Hello @imc67 Sounds like an interesting project you got there, and I would be interested to have a look. @imc67 said: To make it even a community app is totally out of my knowledge and comfort zone, moreover updating the app and being (feeling) responsible for others is too much. That good part about community apps is that they come with zero responsibility. It is up to the maintainer of a community app to maintain, support or improve it. I know that this statement might not do much about your feelings which I can fully understand. Since your project is security related, having this burden on your mind for others that might use it, is much. But, I would be happy to have a look and give my feedback.

@timconsidine Yay works!

I just tried them too - so easy! Can literally copy paste it all as is and then it's done! @gengar

It would be amazing to have AnyType on Cloudron!

@oneinterweb you have to change the credentials in /app/data/env ACKEE_USERNAME=admin ACKEE_PASSWORD=supersecret This works fine.