postgres report premission issue

[hiveer]

Description

starhub-server-postgres-1 | chown: changing ownership of '/var/lib/postgresql/data/base/16385/2696': Permission denied
starhub-server-postgres-1 | chown: changing ownership of '/var/lib/postgresql/data/base/16385/3576': Permission denied
starhub-server-postgres-1 | chown: changing ownership of '/var/lib/postgresql/data/base/16385/19159': Permission denied
starhub-server-postgres-1 | chown: changing ownership of '/var/lib/postgresql/data/base/16385/2662': Permission denied
starhub-server-postgres-1 | chown: changing ownership of '/var/lib/postgresql/data/base/16385/2830': Permission denied
starhub-server-postgres-1 | chown: changing ownership of '/var/lib/postgresql/data/base/16385/3764_vm': Permission denied
starhub-server-postgres-1 | chown: changing ownership of '/var/lib/postgresql/data/base/16385/17833': Permission denied
starhub-server-postgres-1 | chown: changing ownership of '/var/lib/postgresql/data/base/16385/18047': Permission denied
starhub-server-postgres-1 | chown: changing ownership of '/var/lib/postgresql/data/base/16385/2665': Permission denied
starhub-server-postgres-1 | chown: changing ownership of '/var/lib/postgresql/data/base/16385/2838_vm': Permission denied
starhub-server-postgres-1 | chown: changing ownership of '/var/lib/postgresql/data/base/16385/18078': Permission denied
starhub-server-postgres-1 | chown: changing ownership of '/var/lib/postgresql/data/base/16385/2691': Permission denied

docker-compose.yml

  postgres:
    image: "gradescope/postgresql-multiple-databases:14.4"
    user: "root"
    environment:
      POSTGRES_USER: "postgres"
      POSTGRES_PASSWORD: "xxxxx"
      POSTGRES_MULTIPLE_DATABASES: "starhub_server,gitea,mirror"
    ports:
      - "5433:5432"
    volumes:
      - ./pgdata:/var/lib/postgresql/data
    networks:
      - my_network

After I switch to opstack, its working

Version

No response

Operating System

• macOS Intel <= 13 (Ventura)
• macOS Intel >= 14 (Sonoma)
• Apple Silicon <= 13 (Ventura)
• Apple Silicon >= 14 (Sonoma)
• Linux

Output of colima status

No response

Reproduction Steps

1. use docker desktop to run the postgres service
2. switch to colima to run the postgres service

Expected behaviour

No response

Additional context

No response

[unixc3t]

delete existing instance
colima delete

create new instance with vz
colima start --vm-type=vz

[MathiasVandePol]

Can confirm this. I have the same issue even with vm-type set to vz

[MathiasVandePol]

It worked for me doing after adding --mount-type=virtiofs
so:

colima delete 
colima start --vm-type=vz --mount-type=virtiofs

[yusufkandemir]

The behavior when using --vm-type vz and --mount-type virtiofs:

services:
  postgres:
    image: postgres:17.0
    volumes:
      - ./db_data/:/var/lib/postgresql/data
    environment:
      POSTGRES_DB: test_db
      POSTGRES_USER: test_user
      POSTGRES_PASSWORD: test_password
    ports:
      - 5432:5432

$ docker compose up
...
<runs successfully>

$ ls -al
total 8
drwxr-xr-x   4 yusuf  staff  128 Dec 17 00:29 .
drwxr-xr-x@  6 yusuf  staff  192 Dec 17 00:24 ..
-rw-r--r--   1 yusuf  staff  247 Dec 17 00:29 compose.yaml
drwx------  26 yusuf  staff  832 Dec 17 00:29 db_data

$ docker compose exec postgres sh
# ls -al /var/lib/postgresql/data
total 64
drwx------ 26 root     root       832 Dec 16 21:29 .
drwxrwxrwt  1 postgres postgres  4096 Nov 12 09:09 ..
drwx------  6 root     root       192 Dec 16 21:29 base
drwx------ 65 root     root      2080 Dec 16 21:32 global
drwx------  2 root     root        64 Dec 16 21:29 pg_commit_ts
drwx------  2 root     root        64 Dec 16 21:29 pg_dynshmem
-rw-------  1 root     root      5743 Dec 16 21:29 pg_hba.conf
-rw-------  1 root     root      2640 Dec 16 21:29 pg_ident.conf
drwx------  5 root     root       160 Dec 16 21:29 pg_logical
drwx------  4 root     root       128 Dec 16 21:29 pg_multixact
drwx------  2 root     root        64 Dec 16 21:29 pg_notify
drwx------  2 root     root        64 Dec 16 21:29 pg_replslot
drwx------  2 root     root        64 Dec 16 21:29 pg_serial
drwx------  2 root     root        64 Dec 16 21:29 pg_snapshots
drwx------  2 root     root        64 Dec 16 21:29 pg_stat
drwx------  2 root     root        64 Dec 16 21:29 pg_stat_tmp
drwx------  3 root     root        96 Dec 16 21:29 pg_subtrans
drwx------  2 root     root        64 Dec 16 21:29 pg_tblspc
drwx------  2 root     root        64 Dec 16 21:29 pg_twophase
-rw-------  1 root     root         3 Dec 16 21:29 PG_VERSION
drwx------  5 root     root       160 Dec 16 21:29 pg_wal
drwx------  3 root     root        96 Dec 16 21:29 pg_xact
-rw-------  1 root     root        88 Dec 16 21:29 postgresql.auto.conf
-rw-------  1 root     root     30777 Dec 16 21:29 postgresql.conf
-rw-------  1 root     root        36 Dec 16 21:29 postmaster.opts
-rw-------  1 root     root        94 Dec 16 21:29 postmaster.pid

So, instead of the files being owned by postgres:postgres when they are chown'ed within the container, they are owned by root:root within the container and by the host user(e.g. yusuf:staff) in the host machine.

When making some updates to the DB, it breaks. So, even if it launches fine, there is some weird stuff going under the hood, which breaks when interacted with afterward. For example, in a Laravel project, running commands like php artisan db:wipe and php artisan migrate --seed is enough to break it.

@abiosoft, I have done a lot of research about this topic, maybe much more than needed. From what I saw from some comments, it feels like it's known by Lima maintainers and potentially you, but I don't think it's documented anywhere, and not sure if that's true. Is this to be expected, in general, or with certain VM or mount types?