Troubleshooting

This page covers common troubleshooting steps for Canasta installations.

Checking container status

To see if your Canasta containers are running:

cd /path/to/installation
docker compose ps

Viewing container logs

To view logs from the web container:

cd /path/to/installation
docker compose logs web

To follow logs in real-time:

docker compose logs -f web

To view logs from all containers:

docker compose logs

Log file locations

For more detailed debugging, you can access log files inside the container:

Log	Description	Command
Exceptions	Uncaught exceptions (exists by default)	`docker compose exec web tail -f /var/log/mediawiki/exception.log`
Errors	PHP errors (exists by default)	`docker compose exec web tail -f /var/log/mediawiki/error.log`
Fatal errors	Fatal errors (exists by default)	`docker compose exec web tail -f /var/log/mediawiki/fatal.log`
MediaWiki debug	Verbose debug log (opt-in, see below)	`docker compose exec web tail -f /var/log/mediawiki/debug.log`
Apache error	PHP errors and Apache warnings	`docker compose exec web tail -f /var/log/apache2/error_log.current`
Apache access	HTTP request log	`docker compose exec web tail -f /var/log/apache2/access_log.current`

Enabling the MediaWiki debug log

The exception, error, and fatal log files are created automatically. For more verbose debugging, enable the full debug log by adding this to a settings file (e.g., config/settings/global/Debug.php):

<?php
$wgDebugLogFile = '/var/log/mediawiki/debug.log';

Then restart the container:

canasta restart -i myinstance

Accessing the database

To connect to the MariaDB database directly:

canasta maintenance exec -i myinstance -s db -- mariadb -u root -p

Enter the root database password from your .env file (MYSQL_PASSWORD) when prompted.

Running commands inside containers

Use canasta maintenance exec to run commands inside a running container. This works with both Docker Compose and Kubernetes installations.

To list running services:

canasta maintenance exec -i myinstance

To get a shell inside the web container:

canasta maintenance exec -i myinstance -s web

To run a specific command (the default service is web):

canasta maintenance exec -i myinstance -- php -v

To run a command in a different container:

canasta maintenance exec -i myinstance -s db -- mariadb -u root -p

Warning: Files created or modified directly inside a container are not persisted across restarts. Only mounted volumes (.env, config/, extensions/, skins/, images/) survive a canasta stop/canasta start cycle. Use canasta maintenance exec for debugging and inspection, not for permanent configuration changes — use canasta config set, settings files, or wikis.yaml instead.

Common issues

Installation fails with "Canasta installation with the ID already exists"

An installation with that ID is already registered. Use canasta list to see existing installations, or choose a different ID.

Cannot connect to Docker

Ensure Docker is running: systemctl status docker
Ensure your user has Docker access (on Linux: sudo usermod -aG docker $USER, then log out and back in)

Wiki not accessible after creation

Check that containers are running: docker compose ps
Verify the domain/URL configuration in config/wikis.yaml
Check container logs for errors: docker compose logs web

Wiki not accessible on non-standard ports

When using non-standard ports, the port must be included in the URL you use to access the wiki in your browser (e.g., https://localhost:8443, not https://localhost)
The port must also appear in the URL in config/wikis.yaml (e.g., localhost:8443 or localhost:8443/wiki2)
This applies to both path-based and subdomain-based wikis

SSL/TLS errors when running behind a reverse proxy or load balancer

If your server is already behind something that terminates SSL (e.g. Cloudflare, nginx, a cloud load balancer), Caddy's automatic HTTPS will conflict with it. Run canasta config set -i myinstance CADDY_AUTO_HTTPS=off. See Deploying behind a reverse proxy for details.

Permission denied errors

Ensure your user is in the docker and www-data groups (on Linux: sudo usermod -aG docker,www-data $USER, then log out and back in)
The docker group is needed for Docker access; the www-data group is needed because the web container runs as www-data and shares the config/ directory
Ensure the installation directory has proper ownership

Help:Troubleshooting

Contents