Nextcloud Setup Troubleshooting

Nextcloud is a service that enables you to use personal storage like cloud-based data services. Due to its extensive features, it requires not only the core Nextcloud container but also Apache, Redis, MySQL, and more. Additional features like ClamAV, full-text search, Collabora, and Whiteboard are also managed as separate containers. Managing all of these individually can be challenging, so Nextcloud provides an AIO (all-in-one) container. In this post, I’ll cover how to use the AIO container in a rootless environment and document some troubleshooting steps.

Using the AIO Container

You can run the AIO container using the following Quadlet configuration:

# nextcloud_aio.network
[Unit]
Description=Network for nextcloud_aio

[Network]
NetworkName=nextcloud-aio
Driver=bridge

[Install]
WantedBy=default.target

# nextcloud.volume
[Unit]
Description=Nextcloud aio mastercontainer volume

[Volume]
VolumeName=nextcloud_aio_mastercontainer  # Important! Do not change this name.

[Install]
WantedBy=default.target


# nextcloud.container
[Unit]
Description=Nextcloud AIO Master Container
Documentation=https://github.com/nextcloud/all-in-one/blob/main/docker-rootless.md
After=local-fs.target
Requires=podman.socket

[Container]
ContainerName=nextcloud-aio-mastercontainer
Image=docker.io/nextcloud/all-in-one:latest
PublishPort=127.0.0.1:8080:8080
Volume=nextcloud.volume:/mnt/docker-aio-config   # Use nextcloud.volume filename

# Map podman socket for use by spawned containers (replace 1000 with your UID)
Volume=/run/user/1000/podman/podman.sock:/var/run/docker.sock:ro   

# Map backup volume (adjust path to your backup location)
Volume=/path/to/your/backup:/mnt/borgbackup:Z

Network=nextcloud_aio.network
SecurityLabelDisable=true

Environment=APACHE_PORT=11000  # Webserver access port (choose an available port)

# Webserver access IP. Set to 127.0.0.1 for reverse proxy access
Environment=APACHE_IP_BINDING=127.0.0.1  
Environment=WATCHTOWER_DOCKER_SOCKET_PATH=/run/user/1000/podman/podman.sock  # Replace 1000 with your UID

# Path where Nextcloud data will be stored. Mapped by the container later
Environment=NEXTCLOUD_DATADIR=/path/to/your/nextcloud/data

# Path for external data storage (optional)
Environment=NEXTCLOUD_MOUNT=/path/to/your/media
Environment=NEXTCLOUD_UPLOAD_LIMIT=40G
Environment=NEXTCLOUD_MAX_TIME=10800

# Set at least 1GB to avoid PHP memory errors
Environment=NEXTCLOUD_MEMORY_LIMIT=2048M
Environment=NEXTCLOUD_STARTUP_APPS=twofactor_totp
Environment=NEXTCLOUD_ADDITIONAL_APKS=ffmpeg imagemagick
Environment=NEXTCLOUD_ADDITIONAL_PHP_EXTENSIONS=imagick

# Required for VAAPI support in Memories app
Environment=NEXTCLOUD_ENABLE_DRI_DEVICE=true

[Install]
WantedBy=multi-user.target default.target

With this configuration, you can start the container:

systemctl --user daemon-reload
systemctl --user start nextcloud

Access https://<APACHE_IP_BINDING>:<APACHE_PORT> to use the AIO interface to launch the complete Nextcloud setup.

Troubleshooting

External Data Permission Configuration

Simply setting the NEXTCLOUD_MOUNT environment variable is not enough to read and write external data. The data at that path must have appropriate ownership for the www-data user inside the Nextcloud container. Inside the container, www-data has uid:gid = 33:33, but this may differ outside the container. You can check the uid and gid by examining the ownership of the external volume. The typical approach is to change the ownership of all external data to match www-data, but I created a group called “podman” with a gid matching www-data’s external gid. (Simply adding the www-data user to a group doesn’t work because group mappings differ per container.) For example, if www-data’s uid:gid was 123456 externally, I created a podman group with gid=123456, gave the data group ownership to podman, and set permissions to 775 (group write enabled). This allows Nextcloud to access, modify, add, and delete files even without user ownership.

“No MIMEType in EXIF data” Error

You can fix this using Nextcloud’s built-in functionality:

podman exec -it nextcloud-aio-nextcloud php occ maintenance:repair --include-expensive

Administration Checkup Failure

The Security Checkup that runs automatically on the Admin page kept failing. Checking the browser response logs showed 504 timeout errors. This was caused by HAProxy’s server response timeout being set too short at 4s. I resolved it by increasing the timeout to a more typical value of 1m.

.well-known URL Access Issues

To access well-known URLs, you need the following configuration in your HAProxy Frontend:

acl caldav path /.well-known/caldav
acl caldav path /.well-known/caldav/
http-request redirect location /remote.php/dav/ code 301 if caldav

acl carddav path /.well-known/carddav
acl carddav path /.well-known/carddav/
http-request redirect location /remote.php/dav/ code 301 if carddav