Nextcloud Fails to Start on TrueNAS SCALE (Fresh Install, Multiple Attempts)

I need desperate help please team. Please please please!!

Issue Summary

I’ve been trying to install and run Nextcloud on TrueNAS SCALE 24.10.2 without success. I’ve gone through multiple installations, factory resets, and reconfigurations, yet every time I restart TrueNAS, Nextcloud appears in a stopped state. When I attempt to start the app, it fails with the following error:

[EFAULT] Failed ‘up’ action for ‘nextcloud’ app. Please check /var/log/app_lifecycle.log for more details

System Details

  • TrueNAS Version: SCALE 24.10.2
  • Nextcloud Version: 31.0.0 (1.6.9)
  • App Deployment: Official Nextcloud app from the TrueNAS catalog
  • Storage Pool: “Main”
  • Configuration: Nextcloud data directory set to default (/var/www/html/data), other paths remain as ix-apps default
  • TrueNAS Apps Service: Running, but Nextcloud fails on start

Steps Taken

  1. Fresh Installation: I reset TrueNAS to factory defaults multiple times and reinstalled Nextcloud.
  2. Storage Configuration: Initially, I tried mapping the user data to a separate dataset, but later left everything on the default ix-apps path.
  3. Log Analysis:
  • app_lifecycle.log shows container dependencies failing, particularly Postgres.
  • “Pull access denied” errors for Nextcloud containers during startup.
  • Redis and Postgres show errors, possibly indicating permission or container startup issues.
  1. Permissions & Mount Issues: I ensured correct ownership and ACL settings, but no improvement.
  2. App Restart Attempts: After every system reboot, Nextcloud is in a stopped state and cannot be started.

Error Logs (from /var/log/app_lifecycle.log)

Container ix-nextcloud-postgres-1 Error
dependency failed to start: container ix-nextcloud-postgres-1 is unhealthy
Error response from daemon: layer does not exist
nextcloud Warning pull access denied for ix-nextcloud, repository does not exist or may require ‘docker login’: denied: requested access to the resource is denied

More detailed log-----------------------------------
Traceback (most recent call last):
File “/usr/lib/python3/dist-packages/middlewared/job.py”, line 509, in run
await self.future
File “/usr/lib/python3/dist-packages/middlewared/job.py”, line 556, in __run_body
rv = await self.middleware.run_in_thread(self.method, *args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/lib/python3/dist-packages/middlewared/main.py”, line 1367, 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 1364, 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/schema/processor.py”, line 183, in nf
return 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/plugins/apps/app_scale.py”, line 51, in start
compose_action(app_name, app_config[‘version’], ‘up’, force_recreate=True, remove_orphans=True)
File “/usr/lib/python3/dist-packages/middlewared/plugins/apps/compose_utils.py”, line 61, in compose_action
raise CallError(err_msg)
middlewared.service_exception.CallError: [EFAULT] Failed ‘up’ action for ‘nextcloud’ app. Please check /var/log/app_lifecycle.log for more details

What I’m Looking For------------------------

  • Why is Nextcloud failing to start after every reboot?
  • Is there an issue with Postgres initialization in the official TrueNAS SCALE deployment?
  • Is there a workaround for the pull access denied errors for Nextcloud containers?
  • Has anyone successfully deployed Nextcloud on TrueNAS SCALE 24.10.2 without these issues?

Any help would be greatly appreciated. I’ve invested a lot of time trying to troubleshoot this, but I keep ending up in the same state. Thanks in advance!

1 Like

I installed Nextcloud last week on EE with all default settings and selected Postgres 17 instead of 13. No issues at all. Also did the update 31.0.0 earlier this week and also there, no problems.

1 Like

I just tried something to confirm the issue. So it appears that the issue only shows up the moment you restart TRUENAS.

So installing NExtcloud everything runs well and I even backed up the config from TRUENAS. I am able to login into NEXTCLOUD and all,but the moment I RESTART TRUENAS. The nextcloud app doesnt auto restarts and when I force start it doesnt and thts the error that shows up. This is leading me to beliwve its a TRUENAS issue.

I’m having the same issue, on truenas scale (ElectricEel-24.10.2) Nextcloud 1.6.9 fails to install with an ‘up’ error (whatever that means). I even deleted the pool and started right from scratch. Been trying for several days now. Something is seriously broken in 1.6.9

Some up to data guides on installing would also be appreciated. Everything is years out of date.

Any chance we can install an earlier verion on trunas scale to try? All I’m offered is 1.6.9

This was updated last week.

An failed up action means that the docker compose up command failed to deploy the app. To diagnose why, you’d probably need to start with the lifecycle log as suggested by the error message. After failing to deploy, connect to ssh or use the Shell to run sudo cat /var/log/app_lifecyle.log.

Before going there even, can you confirm that you’re using postgres versionn 17 instead of 13, as others have suggested?

Hi No I been trying the POstgres 13 DB but just tried Postgres 17 and stil same error showed up. It works till you reboot TRUENAS.

I’ve tried both 13 and 17. It is borked. It will not install. This is the error message:
Error: Traceback (most recent call last):
File “/usr/lib/python3/dist-packages/middlewared/job.py”, line 509, in run
await self.future
File “/usr/lib/python3/dist-packages/middlewared/job.py”, line 556, in __run_body
rv = await self.middleware.run_in_thread(self.method, *args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/lib/python3/dist-packages/middlewared/main.py”, line 1367, 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 1364, 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 61, in compose_action
raise CallError(err_msg)
middlewared.service_exception.CallError: [EFAULT] Failed ‘up’ action for ‘nextcloud’ app. Please check /var/log/app_lifecycle.log for more details

I’ve had several days at this so I have tried pretty much every iteration by now. I sort of got 1.6.8 working, but it broke irreparably when I tried to use the truenas certificate. Then found it had updated to 1.6.9. and this will not install, period. Been trying about 3-4 days now. I nuked everything, recreated the pool, the datasets and the file locations for the appdata, userdata and the db, (they do not have restrictions, yes I have checked and checked and checked) tried both db 13 and 17, tried with and without the security certificate. Nada. n a d a

This is just ridiculous. Are there any other alternatives to nextcloud available on truenas scale? I really need something like nextcloud, and I need to get this out of the gate.

If there was an option in the drop down to instasll a previous version(s) that would be a very useful thing to have. It is a drop down menu, after all.

I’ve been using my own compose file for half a year now, did 2 or 3 updates and never had problems. You could try to use the custom yml function to deploy nextcloud

Here’s my compose.yml

version: '3.3'
services:
  nextcloud-db:
    image: linuxserver/mariadb:latest
    container_name: nextcloud-db
    restart: unless-stopped
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - /etc/timezone:/etc/timezone:ro
      - /mnt/poolname/datasetname/nextcloud/mariadb/config:/config #Adjust hostpaths before deploying
    environment:
      - PUID=1000
      - PGID=1000
      - MYSQL_ROOT_PASSWORD=supersecretpassword #enter SQL root password
      - MYSQL_PASSWORD=supsersecretpassword #enter SQL password
      - MYSQL_DATABASE=nextcloud #database name
      - MYSQL_USER=nextcloud #SQL username
      - MYSQL_INITDB_SKIP_TZINFO=1
      - MARIADB_AUTO_UPGRADE=1
    ports:
      - 3306:3306
  nextcloud-redis:
    image: redis:alpine
    container_name: nextcloud-redis
    hostname: nextcloud-redis
    networks:
        - default
    restart: unless-stopped
    command: redis-server --requirepass nextcloud # Redis Passwort eingeben
  nextcloud-app:
    image: linuxserver/nextcloud:latest
    container_name: nextcloud-app
    restart: unless-stopped
    depends_on:
      - nextcloud-db
      - nextcloud-redis
    environment:
      - PUID=1000
      - PGID=1000
      - TRUSTED_PROXIES="**"
      - OVERWRITEPROTOCOL=https
      - OVERWRITECLIURL=domainname or ip
      - OVERWRITEHOST= domainame or ip
      - REDIS_HOST= nextcloud-redis
      - REDIS_HOST_PASSWORD= nextcloud # enter Redis password 
    ports:
      - '11080:80'
    volumes:
      -  /mnt/poolname/datasetname/nextcloud/config:/config #adjust storage paths
      - /mnt/poolname/datasetname/nextcloud:/data #adjust storage paths for user data
    labels:
      - "traefik.enable=true" # delete if you're not using traefik as reverse proxy
      - "traefik.docker.network=proxy" # delete if you're not using traefik as reverse proxy
      - "traefik.http.routers.nextcloud.rule=Host(`cloud.mydomain.com`)" # delete if you're not using traefik as reverse proxy
      - "traefik.http.routers.nextcloud.entrypoints=https" # delete if you're not using traefik as reverse proxy
      - "traefik.http.routers.nextcloud.tls=true" # delete if you're not using traefik as reverse proxy
      - "traefik.http.services.nextcloud.loadbalancer.server.port=80" # delete if you're not using traefik as reverse proxy
      - "traefik.http.routers.nextcloud.tls.certresolver=cloudflare" # delete if you're not using traefik as reverse proxy
    networks:
      - proxy # delete if you're not using traefik as reverse proxy
      - default
networks: # delete if you're not using traefik as reverse proxy
  proxy: # delete if you're not using traefik as reverse proxy
    external: true # delete if you're not using traefik as reverse proxy

as I said earlier, you need to run sudo cat /var/log/app_lifecyle.log

This was likely due to an incorrect setting (or no setting) in Host. You would need to modify the Nextcloud config.php for overwrite host and then restart the container. I’ve seen a few posts that talk about how to do that in various threads.

hey everyone, I am experiencing the same issue with TN EE and Nextcloud. I’ve followed the instructions from the TN HUB https://www.truenas.com/docs/truenasapps/stableapps/nextcloud/#expand-1
but get the following error using Postgres 17

Container ix-nextcloud-postgres_upgrade-1  service "postgres_upgrade" didn't complete successfully: exit 2
service "postgres_upgrade" didn't complete successfully: exit 2

Any assistance is greatly appreciated.

This is almost definitely a permissions issue. My suggestion is to start over with the postgres dataset. Create a new postgres dataset. Set the preset to Generic. Don’t do anything else to the dataset. In the Storage Configuration section of a new Nextcloud install, set Nextcloud Postgres Data Storage to Host Path, set the path to the new dataset, and click Automatic Permissions.

Thanks for the suggestion and I will try that… but it contradicts the TN instructions for setting up datasets for NC. Unless I’m reading it wrong… highly likely.
https://www.truenas.com/docs/truenasapps/stableapps/nextcloud/#expand-1

  1. Enter the name of the dataset, then select Apps as the Dataset Preset. Creating the parent dataset with the preset set to Generic causes permissions issues when you try to create the datasets the app requires with the preset set to Apps.
  2. Click Save. Return to dataset creation when prompted rather than configuring ACL permissions.You can set up permissions (ACLs) for a dataset after adding it by selecting Go to ACL Manager to open the Edit ACL screen, or wait and use the app Install wizard ACL settings to add permissions. You can also edit permissions after installing the app using either method.
  3. Select the parent dataset and then click Create Dataset to open the Add Dataset screen again.
  4. Enter the name of a dataset required for the app, such as config, select Apps as the Dataset Preset, and then click Save. When prompted, return to creating datasets rather than setting up ACL permissions.

Hmm I may be misremembering that it should be Apps instead of Generic. I guess try one and then the other if it fails.

The rest of what I’m talking about is just below that expand

When storage volumes include a postgres dataset, do not select Enable ACL to configure permissions. Instead, proceed with entering or browsing to select the dataset and populate the Host Path field, then select the Automatic Permissions option. This configures permissions for the postgres dataset and, if configured, the parent dataset used to organize required datasets for the app.

yeah I’ve done what that expand says. and I think I’ve done it both ways already… been monkeying around for a couple of days with this. I agree with your assessment tho, permissions.

so I was successful by leaving all as is, but checkmark the Force Flag (which was omitted in the instructions)

Interesting since that force flag refers to User Data storage, not Postgres. Did you enable it for all the host paths?

PURE LUCK - Don’t count on it working twice. . .

yes I did. But to be honest, I’ve done this so many times… who knows… I may try building a 2nd instance to see if I have success.