Self‑hosting WordPress sounds simple: “just run a container and you’re done”. In reality, if you’re doing it on OpenMediaVault (OMV) with Docker, paths, volumes, and passwords can easily trip you up.

This guide walks through how to set up WordPress + MariaDB in a single Docker stack on OpenMediaVault, and the common problems that can appear along the way:

• missing folders under /srv,
• the infamous No such file or directory when saving docker-compose.yml,
• and having to completely reset WordPress + MariaDB after I lost the admin password.

If you’re running OMV with Docker and want a clean, reproducible setup, this is for you.

---

🖥️ Environment overview

Here’s what a typical environment looks like:

• OpenMediaVault (OMV) running on a box with:
  • an NVMe disk as the main system drive (/),
  • optional RAID disks (sda, sdb),
  • Docker installed via OMV‑Extras.
• I want WordPress + MariaDB running as a single Docker Compose stack.
• I don’t want to hand‑write a custom frontend; I want a classic WordPress blog.

It’s easy to assume that OMV will expose data disks under paths like:

/srv/dev-disk-by-uuid-<UUID>

But when I ran:

ls -l /srv

I only saw OMV’s internal folders like pillar and salt, and no data disks at all. That raises an important question: where should Docker volumes actually be stored?

---

📂 Choosing where to store WordPress data

Running lsblk -f showed that my main NVMe partition was already mounted as /:

nvme0n1p2  ext4  ...  MOUNTPOINT /

This meant I didn’t actually need to use /srv/dev-disk-by-uuid-... yet. I could simply store my Docker data under /srv on the root filesystem and keep things simple.

A practical layout is:

/srv/docker/wordpress/
  ├── docker-compose.yml
  ├── db_data/   # MariaDB data
  └── wp_data/   # WordPress files (wp-content, plugins, uploads)

This is a good compromise:

• It keeps everything Docker‑related under /srv/docker.
• It avoids dealing with extra mounts or UUID paths until I really need them.

Pitfall #1 – No such file or directory when saving docker-compose.yml

One of the first common problems looks like this: opening nano like this:

sudo nano /srv/docker/wordpress/docker-compose.yml

and seeing:

[ Error writing /srv/docker/wordpress/docker-compose.yml: No such file or directory ]

The reason was simple: the directory /srv/docker/wordpress did not exist yet.

The fix was also simple, but easy to overlook:

sudo mkdir -p /srv/docker/wordpress
sudo mkdir -p /srv/docker/wordpress/db_data
sudo mkdir -p /srv/docker/wordpress/wp_data

Once those directories exist, nano can save docker-compose.yml without errors.

Lesson: Always create your directory structure before you try to save files into it.

---

🧱 The docker-compose.yml for WordPress + MariaDB

Here is an example docker-compose.yml that works well in this setup:

version: "3.9"

services:
  db:
    image: mariadb:11
    container_name: wordpress_mariadb
    restart: unless-stopped
    environment:
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wp_user
      MYSQL_PASSWORD: wp_user_password_here        # change to strong password
      MYSQL_ROOT_PASSWORD: root_password_here      # change to strong password
    volumes:
      - /srv/docker/wordpress/db_data:/var/lib/mysql
    networks:
      - wp_net

  wordpress:
    image: wordpress:6.7-php8.3-apache
    container_name: wordpress_app
    restart: unless-stopped
    depends_on:
      - db
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_USER: wp_user
      WORDPRESS_DB_PASSWORD: wp_user_password_here # must match MYSQL_PASSWORD
      WORDPRESS_DB_NAME: wordpress
    volumes:
      - /srv/docker/wordpress/wp_data:/var/www/html
    ports:
      - "8080:80"   # http://<OMV_IP>:8080 → WordPress
    networks:
      - wp_net

networks:
  wp_net:
    driver: bridge

A few important points:

• The database credentials for WordPress (WORDPRESS_DB_*) must match what you set in the MariaDB service (MYSQL_*).
• The host paths /srv/docker/wordpress/db_data and /srv/docker/wordpress/wp_data are where your persistent data lives.
• The WordPress container is published on port 8080, so the site will be reachable at http://<OMV_IP>:8080.

---

🚀 Starting the stack

From the directory that contains docker-compose.yml:

cd /srv/docker/wordpress
sudo docker compose up -d

You can then check that the containers are running:

sudo docker ps

You should see something like:

CONTAINER ID   IMAGE                              PORTS                   NAMES
...            wordpress:6.7-php8.3-apache        0.0.0.0:8080->80/tcp    wordpress_app
...            mariadb:11                         3306/tcp                wordpress_mariadb

To find your OMV server’s IP address, run:

hostname -I

Then open a browser and go to:

http://<OMV_IP>:8080

You should see the classic WordPress installation screen.

---

🔐 WordPress installation

On the WordPress installer screen you choose:

• Site Title
• Username (admin login)
• Password (for the WordPress admin user)
• Email

After submitting the form, WordPress creates the admin account and the dashboard becomes available at:

http://<OMV_IP>:8080/wp-admin

Make sure to store the credentials securely (for example, in a password manager) so they are easy to reuse later.

---

🔄 Resetting WordPress + MariaDB (clean reinstall)

If you want to completely start over with a clean WordPress + MariaDB environment (for example, for testing or after experimenting with settings), you need to:

1. Stop and remove the containers.
2. Delete the data directories (db_data and wp_data).
3. Start the stack again so WordPress and MariaDB re‑initialize from scratch.

Step 1 – Stop and remove containers

From the project directory:

cd /srv/docker/wordpress
sudo docker compose down

This removes the wordpress_app and wordpress_mariadb containers but leaves the data on disk.

Step 2 – Delete old data

Now remove everything inside the data directories:

sudo rm -rf /srv/docker/wordpress/db_data/*
sudo rm -rf /srv/docker/wordpress/wp_data/*

⚠️ Be very careful with rm -rf. Double‑check the paths before pressing Enter.

After this, MariaDB has no database files, and WordPress has no site files – it’s like a brand‑new install.

Step 3 – Start the stack again

Run:

cd /srv/docker/wordpress
sudo docker compose up -d

Then open http://<OMV_IP>:8080 again. You will see the WordPress installer just like the first time.

On a reinstall, it’s a good idea to:

• choose a strong password,
• save it in a password manager,
• and verify it by logging in immediately after installation.

---

💡 Lessons learned

A few practical takeaways from this whole process:

1. Create directories first

If you see errors like:

[ Error writing /srv/docker/wordpress/docker-compose.yml: No such file or directory ]

it almost always means that the parent directory doesn’t exist yet. Use:

sudo mkdir -p /srv/docker/wordpress

before trying to save or mount anything there.

2. Keep Docker data in a clear, simple path

Using /srv/docker/... on the root filesystem works fine, especially when you’re just starting. You can always move to a dedicated data disk later and update your volume paths.

3. Separate DB credentials from WordPress admin credentials

There are two kinds of passwords in play:

• MariaDB passwords (in docker-compose.yml):
  • MYSQL_PASSWORD
  • MYSQL_ROOT_PASSWORD
• WordPress admin password (set in the web installer):
  • Username + password you type in the browser.

The WordPress admin credentials are independent from the values in docker-compose.yml. The compose file configures the database connection; the admin username and password are managed inside WordPress itself.

4. Reinstalling is sometimes the fastest “fix”

On a fresh setup with no real content, fully resetting WordPress + MariaDB is often easier than manually editing tables in phpMyAdmin. Stopping the stack, deleting db_data and wp_data, and starting again gives you a clean slate in a minute or two.

5. Document your paths and ports

It’s easy to forget whether you used /srv/docker/wordpress or /srv/dev-disk-by-uuid-..., or whether you exposed port 8080 or 8000.

It helps to keep a small note with:

• the full path to the project:
  • /srv/docker/wordpress
• the volumes:
  • /srv/docker/wordpress/db_data:/var/lib/mysql
  • /srv/docker/wordpress/wp_data:/var/www/html
• the access URL:
  • http://<OMV_IP>:8080

It makes future debugging and migrations much easier.

---

👉 What’s next?

Once WordPress is up and running on OMV, the next logical steps are:

• Put it behind a reverse proxy (like Nginx Proxy Manager) and expose it via HTTPS.
• Configure backups for both wp_data and db_data.
• Install a theme and some essential plugins (SEO, security, backups).

But the core foundation is this: a solid Docker stack with clear volumes and a process for resetting when something goes wrong. Once that part is reliable, the rest of the blog experience becomes much more enjoyable.