Container hangs at "Enabling Imagick..." after automated backup restart

The Basics

  • Installation method (e.g. AlO, NCP, Bare Metal/Archive, etc.)
    • Nextcloud AIO v11.3.0
  • Nextcloud Server version (e.g., 29.x.x):
    • Nextcloud 31.0.6
  • Operating system and version (e.g., Ubuntu 24.04):
    • Debian 12 (Version 12.11)
  • Reverse proxy and version _(e.g. nginx 1.27.2)
    • Caddy 2.6.2 (running on VPS)
  • Custom Environment Variables
  - APACHE_PORT=11000
  - APACHE_IP_BINDING=0.0.0.0
  - SKIP_DOMAIN_VALIDATION=false
  - PHP_DEFAULT_SOCKET_TIMEOUT=1200
  - PHP_MEMORY_LIMIT=2048M
  • Is this the first time you’ve seen this error? (Yes / No):

    • No
  • When did this problem seem to first start?

    • Since setting up the AIO two weeks ago
  • Are you using CloudfIare, mod_security, or similar? (Yes / No)

    • I don't think so

Summary of the issue you are facing:

The nextcloud-aio-nextcloud container consistently gets stuck after the scheduled internal backup process completes. The last visible log message is ā€œEnabling Imagickā€¦ā€, after which the container hangs, making the entire Nextcloud instance inaccessible until a manual intervention is performed.

Steps to replicate it (hint: details matter!):

  1. Configure a scheduled backup in the Nextcloud AIO Interface.
  2. Let the scheduled backup run automatically.
  3. After the backup completes, the AIO mastercontainer attempts to restart all stopped containers.
  4. Observe that the nextcloud-aio-nextcloud container hangs and never becomes healthy.

Log entries

nextcloud-aio-nextcloud

              now              
-------------------------------
2025-07-17 06:50:27.941412+00
(1 row)
+ '[' -f /dev-dri-group-was-added ']'
++ find /dev -maxdepth 1 -mindepth 1 -name dri
+ '[' -n '' ']'
+ set +x
Enabling Imagick...

Configuration

Nextcloud

Output of occ config:list system

docker exec -u www-data nextcloud-aio-nextcloud php /var/www/html/occ config:list system
{
    "system": {
        "one-click-instance": true,
        "one-click-instance.user-limit": 100,
        "memcache.local": "\\OC\\Memcache\\APCu",
        "apps_paths": [
            {
                "path": "\/var\/www\/html\/apps",
                "url": "\/apps",
                "writable": false
            },
            {
                "path": "\/var\/www\/html\/custom_apps",
                "url": "\/custom_apps",
                "writable": true
            }
        ],
        "check_data_directory_permissions": false,
        "memcache.distributed": "\\OC\\Memcache\\Redis",
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "password": "***REMOVED SENSITIVE VALUE***",
            "port": 6379
        },
        "overwritehost": "my.dyndns.here",
        "overwriteprotocol": "https",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "localhost",
            "my.dyndns.here"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "pgsql",
        "version": "31.0.6.2",
        "overwrite.cli.url": "https:\/\/my.dyndns.here\/",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "maintenance": false,
        "updatechecker": false,
        "loglevel": 2,
        "log_type": "file",
        "logfile": "\/var\/www\/html\/data\/nextcloud.log",
        "log_rotate_size": 10485760,
        "log.condition": {
            "apps": [
                "admin_audit"
            ]
        },
        "preview_max_x": 2048,
        "preview_max_y": 2048,
        "jpeg_quality": 60,
        "enabledPreviewProviders": {
            "1": "OC\\Preview\\Image",
            "2": "OC\\Preview\\MarkDown",
            "3": "OC\\Preview\\MP3",
            "4": "OC\\Preview\\TXT",
            "5": "OC\\Preview\\OpenDocument",
            "6": "OC\\Preview\\Movie",
            "7": "OC\\Preview\\Krita",
            "0": "OC\\Preview\\Imaginary",
            "23": "OC\\Preview\\ImaginaryPDF"
        },
        "enable_previews": true,
        "upgrade.disable-web": true,
        "mail_smtpmode": "smtp",
        "trashbin_retention_obligation": "auto, 30",
        "versions_retention_obligation": "auto, 30",
        "activity_expire_days": 30,
        "simpleSignUpLink.shown": false,
        "share_folder": "\/Shared",
        "one-click-instance.link": "https:\/\/nextcloud.com\/all-in-one\/",
        "upgrade.cli-upgrade-link": "https:\/\/github.com\/nextcloud\/all-in-one\/discussions\/2726",
        "updatedirectory": "\/nc-updater",
        "maintenance_window_start": 100,
        "allow_local_remote_servers": true,
        "davstorage.request_timeout": 3600,
        "documentation_url.server_logs": "https:\/\/github.com\/nextcloud\/all-in-one\/discussions\/5425",
        "htaccess.RewriteBase": "\/",
        "dbpersistent": false,
        "auth.bruteforce.protection.enabled": true,
        "ratelimit.protection.enabled": true,
        "files_external_allow_create_new_local": false,
        "trusted_proxies": "***REMOVED SENSITIVE VALUE***",
        "preview_imaginary_url": "***REMOVED SENSITIVE VALUE***",
        "preview_imaginary_key": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpsecure": "ssl",
        "mail_sendmailmode": "smtp",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "465",
        "mail_smtpauth": true,
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
        "data-fingerprint": "09d349fd9737a7fb78bf2dc85e19fa29",
        "memories.db.triggers.fcu": true,
        "memories.exiftool": "\/var\/www\/html\/custom_apps\/memories\/bin-ext\/exiftool-amd64-musl",
        "memories.vod.path": "\/var\/www\/html\/custom_apps\/memories\/bin-ext\/go-vod-amd64",
        "memories.vod.ffmpeg": "\/usr\/bin\/ffmpeg",
        "memories.vod.ffprobe": "\/usr\/bin\/ffprobe",
        "DOMAIN": "my.dyndns.here"
    }
}

Apps

The output of occ app:list (if possible).

docker exec -u www-data nextcloud-aio-nextcloud php /var/www/html/occ app:list
Enabled:
  - activity: 4.0.0
  - admin_audit: 1.21.0
  - bookmarks: 15.1.2
  - bruteforcesettings: 4.0.0
  - calendar: 5.3.5
  - circles: 31.0.0
  - cloud_federation_api: 1.14.0
  - comments: 1.21.0
  - contacts: 7.1.5
  - contactsinteraction: 1.12.0
  - dashboard: 7.11.0
  - dav: 1.33.0
  - deck: 1.15.1
  - federatedfilesharing: 1.21.0
  - federation: 1.21.0
  - files: 2.3.1
  - files_downloadlimit: 4.0.0
  - files_pdfviewer: 4.0.0
  - files_reminders: 1.4.0
  - files_sharing: 1.23.1
  - files_trashbin: 1.21.0
  - files_versions: 1.24.0
  - firstrunwizard: 4.0.0
  - integration_paperless: 1.0.6
  - logreader: 4.0.0
  - lookup_server_connector: 1.19.0
  - memories: 7.6.0
  - news: 26.0.2
  - nextcloud-aio: 0.8.0
  - nextcloud_announcements: 3.0.0
  - notifications: 4.0.0
  - notify_push: 1.1.0
  - oauth2: 1.19.1
  - password_policy: 3.0.0
  - photos: 4.0.0-dev.1
  - previewgenerator: 5.9.0
  - privacy: 3.0.0
  - profile: 1.0.0
  - provisioning_api: 1.21.0
  - recognize: 9.0.3
  - recommendations: 4.0.0
  - related_resources: 2.0.0
  - serverinfo: 3.0.0
  - settings: 1.14.0
  - sharebymail: 1.21.0
  - support: 3.0.0
  - survey_client: 3.0.0
  - systemtags: 1.21.1
  - tasks: 0.16.1
  - text: 5.0.0
  - theming: 2.6.1
  - twofactor_backupcodes: 1.20.0
  - twofactor_totp: 13.0.0-dev.0
  - updatenotification: 1.21.0
  - user_status: 1.11.0
  - viewer: 4.0.0
  - weather_status: 1.11.0
  - webhook_listeners: 1.2.0
  - workflowengine: 2.13.0
Disabled:
  - app_api: 5.0.2 (installed 5.0.2)
  - encryption: 2.19.0
  - files_external: 1.23.0
  - suspicious_login: 9.0.1
  - twofactor_nextcloud_notification: 5.0.0
  - user_ldap: 1.22.0

Expected Behaviour The container should fully start after the backup process is complete.

Actual Behaviour The container’s startup process halts. The final entry in the Docker logs for the container is Enabling Imagick.... The container remains in this unresponsive state indefinitely.

Workaround The only way to recover the instance is a specific manual restart sequence:

  1. Manually stop all AIO containers.
  2. Manually start only the nextcloud-aio-mastercontainer.
  3. The mastercontainer then starts all dependent containers. However, sometimes the nextcloud-aio-nextcloud container requires one additional, manual restart before the instance becomes fully available.

Diagnostic Hypothesis
While the log indicates the process hangs at ā€œEnabling Imagickā€¦ā€, an investigation inside the unresponsive container suggests a possible root cause.

Connecting via docker exec revealed a running process that appears to be stuck:
Bash

# ps aux | grep apk
root         32  0.0  0.0  12048 10156 ?        S    06:01   0:00 apk add --no-cache --virtual .docker-php-ext-enable-deps binutils

This suggests the entrypoint script may be hanging on a package installation command that runs after the Imagick step, possibly due to a network timing issue. Any subsequent manual attempt to run apk fails with a database lock error.

Additional Troubleshooting Information
The following configuration changes have been tried and did not solve the problem, pointing away from a simple environment issue:

The Docker daemon is configured with static DNS servers in /etc/docker/daemon.json.

The MTU of the Docker network has been set in /etc/docker/daemon.json to match the MTU of the Wireguard interface (wg0). 

(as per first Installation stops by "Enabling Imagick..." in nextcloud-aio-nextcloud container Ā· nextcloud/all-in-one Ā· Discussion #4512 Ā· GitHub)

Any help or suggestions on how to approach this would be greatly appreciated.

Hi,
I recently encountered an issue with Imagick in AIO, specifically missing SVG support that caused the container to fail during startup. I documented the solution here:
:backhand_index_pointing_right: Tutorial: Missing SVG support in the imagick module in Nextcloud AIO

What helped in my case was adding the following environment variable:

environment:
  - NEXTCLOUD_ADDITIONAL_APKS=imagemagick

This should be added under the nextcloud-aio-mastercontainer section of your docker-compose.yml.
It ensures that the imagemagick package is installed during container startup.

Then restart the containers.

Give it a try and see if it resolves the hang on the Enabling imagick step.
For me, this fixed a similar issue.

Hi,
Thanks for your suggestion. Unfortunately, this didn’t solve the issue.

I added the NEXTCLOUD_ADDITIONAL_APKS=imagemagick environment variable to the nextcloud-aio-mastercontainer section in my docker-compose.yml and restartet the containers.

After a backup, the nextcloud-aio-nextcloud container still gets stuck at ā€œEnabling Imagickā€¦ā€. Interestingly, this problem only occurs after a backup. On a fresh, initial startup, everything works perfectly.

After a successful initial startup, I checked the logs:

2025-07-17T09:00:12.401326460Z Enabling Imagick... 2025-07-17T09:00:14.752228973Z WARNING: opening from cache https://dl-cdn.alpinelinux.org/alpine/v3.21/main: No such file or directory 2025-07-17T09:00:14.752248643Z WARNING: opening from cache https://dl-cdn.alpinelinux.org/alpine/v3.21/community: No such file or directory

The log warnings lead me to believe that the container is unable to connect to the Alpine Linux package repositories (alpinelinux.org) to install imagemagick. My hypothesis is that something is blocking the nextcloud-aio-nextcloud container’s network access. For some reason that only affects container restarts, but never the first run.

Btw: The problem (ā€œEnabling Imagickā€¦ā€) persisted after updating to Nextcloud AIO v11.4.0 just now

I am sure that @szaimen will be more helpful with his suggestions in this case.

1 Like

Are you certain you don’t have NEXTCLOUD_ADDITIONAL_PHP_EXTENSIONS set in your Compose?

This is my docker-compose.yml:

services:
  nextcloud-aio-mastercontainer:
    image: ghcr.io/nextcloud-releases/all-in-one:latest
    init: true
    restart: always
    container_name: nextcloud-aio-mastercontainer
    environment:
      - APACHE_PORT=11000
      - APACHE_IP_BINDING=0.0.0.0
      - SKIP_DOMAIN_VALIDATION=false
      - PHP_DEFAULT_SOCKET_TIMEOUT=1200
      - PHP_MEMORY_LIMIT=2048M
      - NEXTCLOUD_ADDITIONAL_APKS=imagemagick
    ports:
      - 8081:8080
    volumes:
      - nextcloud_aio_mastercontainer:/mnt/docker-aio-config
      - /var/run/docker.sock:/var/run/docker.sock:ro

volumes:
  nextcloud_aio_mastercontainer:
    name: nextcloud_aio_mastercontainer

My bad I also just realized that imagick is automatically added to that variable.

When you changed the MTU in daemon.json did you recreate your AIO network? See Docker: Default network options.

I have the same problem after update to 31.0.7 (wireguard, aoi, hang at imagick, restart master container and nextcloud helps). How and where can I change the MTU in docker.json (of which interface) to fix this issue?

I determined my wg0 MTU by running ip link show wg0 on my host machine, as I suspect wg0 (WireGuard’s interface) is the relevant network interface causing issues.

To change the MTU in Docker, I edited /etc/docker/daemon.json to include:

JSON{ "mtu": 1420 }

(Replace 1420 with your wg0 interface’s MTU.) Then restart Docker: sudo systemctl restart docker.

I referenced a guide similar to https://www.civo.com/learn/fixing-networking-for-docker for this.

This hasn’t fully solved it for me yet. I still need to try recreating Docker networks as suggested by jtr above. I think that is step two of the link.

Thanks, yes, my native wireguard interface (over which I serve my local nextcloud aio) has an MTU of 1420, my netbird (also wireguard in the end) interface (probably irrelevant for this) has an MTU of 1280, and all vethxxx docker interfaces have indeed an MTU of 1500.

However, restarting the master and nextcloud container always resolves the backup-induced imagick hang for me. So why is the MTU (or recreating the docker network interfaces) here the problem (yes, I read your guide, but shouldn’t there then be much more timeouts somewhere than at container start -or does the MTU get automatically adjusted somewhere at kernel level later in docker?)? I disabled the backup option now (ā€œonlyā€ family server), and aio seems to run stable. If the MTU option were wrong, wouldn’t I see tons of other network connectivity problems?

So, I agree that it seems to be a networking problem, but I don’t understand why it only happens when the master container stops and starts the nextcloud container and not when I stop and start it. It seems to me that there should be another ā€œrootā€ cause.

Regarding MTU, I’m unsure. User L0rz mentioned that modifying the MTU resolved their Imagick problem (as seen in this discussion: first Installation stops by "Enabling Imagick..." in nextcloud-aio-nextcloud container Ā· nextcloud/all-in-one Ā· Discussion #4512 Ā· GitHub). It didn’t work for me, but then again, I’m not certain if I correctly altered my existing Docker network or how one would ā€œrecreateā€ it.

One workaround I’ve been thinking about involves a cron job that runs every morning. After Nextcloud is backed up and updated, it would:

  1. Stop the nextcloud-aio-mastercontainer and nextcloud-aio-nextcloud Docker containers.
  2. Start nextcloud-aio-mastercontainer.
  3. Start nextcloud-aio-nextcloud (which consistently pauses at Enabling Imagick... initially).
  4. And then, yes, restart nextcloud-aio-nextcloud one more time.

This approach ensures I have both backups and an updated Nextcloud, all while successfully getting past the ā€œEnabling Imagickā€¦ā€ hang-up. What causes the issue, though, remains a mystery.

Quick update: For the past four days, the problem is gone! My automated backups and updates run, and crucially, the containers now start perfectly afterward without hanging at ā€œEnabling Imagickā€¦ā€ I haven’t had to use any workarounds.

I don’t really know why it works now, though. Still using the docker-compose.yml file I posted earlier. Fingers crossed it stays this way!

Thanks! So, to summarize: you use the socket timeout and imagemagick extra app in docker compose as well as the mtu settings for docker? And that all together does the trick?

I implemented socket timeout and the extra app but forgot the mtu change last night and it crashed again. I will report if adding the mtu works tomorrow.

No improvement. None of this fixes the hang at enabling imagick after backup. I am going to disable the built in backup and do my own without container restart.

Today, the problem returned. The nextcloud-aio-nextcloud container got stuck on ā€œEnabling Imagickā€¦ā€ after a backup and update.

And after the latest update, it seems like I cannot get past the enabling Imagick at all. Can I manually kill the enabling imagick somehow per shell in the docker container to make it proceed?

1 Like

yes, killing the task for enabling the imagick extension allows the startup to proceed.

I get in the log then:

Enabling Imagick ← seems to wait forever here and blocking all other nextcloud services

Terminated

Could not install PHP extension imagick!

and then it seems to proceed but marks nextcloud container as unhealthy

but another restart then fixed it and let nextcloud start

Same here. The ā€œEnabling Imagickā€ bug continues to be annoying

Same issue here.
I’ve running many other containers on the same docker instance. I don’t have knowledge about the MTU. Is it possible to change the MTU of the wg0 interface on both sides of the VPN connection to 1500? I’d guess that changing the MTU on the docker intance to 1420 might influence other containers running on it…

After searching around a lot, I found this commit:

It adds some documentation to the README and the compose.yaml how to configure the mastercontainer to work with a network that has a different MTU.
This solved it for me.

1 Like