From: | Pavel Hushcha <paul(dot)fastest(at)gmail(dot)com> |
---|---|
To: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Issue with PostgreSQL 18.0 Docker image volume mount (/var/lib/postgresql/data symlink) |
Date: | 2025-09-26 05:53:09 |
Message-ID: | EBBF5188-08B7-4434-9324-9FC9D67C3A94@gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Hello,
I’ve encountered a problem when trying to upgrade from the `postgres:17.6` Docker image to `postgres:18.0`.
With PostgreSQL 17.6, the volume mapping worked fine:
```yaml
volumes:
- /volumeUSB1/usbshare1-6/configs/postgresql/data:/var/lib/postgresql/data/
```
However, with `postgres:18.0`, the container fails to start with the following error:
```
Error response from daemon: failed to create task for container: failed to create shim task:
OCI runtime create failed: runc create failed: unable to start container process:
error during container init: error mounting "/volumeUSB1/usbshare1-6/configs/postgresql/data"
to rootfs at "/var/lib/postgresql/data": change mount propagation through procfd:
open o_path procfd: open /volumeUSB1/usbshare1-6/docker/btrfs/subvolumes/362b5618ea6ff38caa0671921e892066b3ad705e39270f938aac396f7401781e/var/lib/postgresql/data:
no such file or directory: unknown
```
I noticed that the difference is in the Docker image itself:
* In 17.6, `/var/lib/postgresql/data` is a real directory.
* In 18.0, `/var/lib/postgresql/data` is a symlink to `.`.
This change seems to break bind mounts on some storage backends (in my case, Btrfs on a Synology NAS).
Could you confirm if this symlink change in the official PostgreSQL 18.0 Docker image is intentional?
And if so, is there a recommended way to mount external volumes for `PGDATA` now?
Thanks,
Pavel Hushcha
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2025-09-26 07:36:24 | BUG #19064: Trigger allows creation with invalid column references but fails at runtime |
Previous Message | David Rowley | 2025-09-25 21:42:19 | Re: The issue of incorrect width estimation in UNION queries |