Affected area
Database
Supabase CLI version
v2.110.0
Operating system
Fedora 44
Installation method
npm
Command
export DOCKER_HOST="unix://${XDG_RUNTIME_DIR}/podman/podman.sock"
supabase db pull
Actual output
The image-pull progress is omitted below. The command otherwise ran with no custom migrations or configuration changes and failed during the default pg-delta schema diff:
Initialising login role...
Creating shadow database...
Initialising schema...
Seeding globals from roles.sql...
Diffing schemas...
Trying to pull public.ecr.aws/supabase/edge-runtime:v1.74.2...
...
error diffing schema: error running script:
Error: Failed to read certificate file '/workspace/supabase/.temp/pgdelta/pgdelta-target-ca.crt': EACCES: permission denied, open '/workspace/supabase/.temp/pgdelta/pgdelta-target-ca.crt'
at getCertValue (file:///var/tmp/sb-compile-edge-runtime/node_modules/localhost/@supabase/pg-delta/1.0.0-alpha.32/dist/core/plan/ssl-config.js:44:27)
at async parseSslConfig (file:///var/tmp/sb-compile-edge-runtime/node_modules/localhost/@supabase/pg-delta/1.0.0-alpha.32/dist/core/plan/ssl-config.js:62:23)
at async createManagedPool (file:///var/tmp/sb-compile-edge-runtime/node_modules/localhost/@supabase/pg-delta/1.0.0-alpha.32/dist/core/postgres-config.js:340:23)
at async resolvePool (file:///var/tmp/sb-compile-edge-runtime/node_modules/localhost/@supabase/pg-delta/1.0.0-alpha.32/dist/core/plan/create.js:48:29)
at async resolveCatalog (file:///var/tmp/sb-compile-edge-runtime/node_modules/localhost/@supabase/pg-delta/1.0.0-alpha.32/dist/core/plan/create.js:63:26)
at async createPlan (file:///var/tmp/sb-compile-edge-runtime/node_modules/localhost/@supabase/pg-delta/1.0.0-alpha.32/dist/core/plan/create.js:71:27)
at async file:///var/tmp/sb-compile-edge-runtime/index.ts:52:18
PGDELTA_SCRIPT_ERROR
runtime has escaped from the event loop unexpectedly: event loop error: Error
at file:///var/tmp/sb-compile-edge-runtime/index.ts:96:9
main worker has been destroyed
event loop error: Error
at file:///var/tmp/sb-compile-edge-runtime/index.ts:96:9
Try rerunning the command with --debug to troubleshoot the error.
Exit Code: 1
The generated CA file was mode `0644`, but had the normal workspace SELinux type `user_home_t`. The helper container runs with the `container_t` domain, so SELinux rejects the read despite the Unix permissions.
Expected behavior
supabase db pull should complete with its default diff engine when the CLI is connected to a rootless Podman Docker-compatible socket on an SELinux-enforcing host. It should not require the user to relabel CLI-generated temporary artifacts manually.
Steps to reproduce
- keep SELinux enforcing
systemctl --user start podman.socket, ensure it is rootless
- Point CLI at Podman socket, e.g.
export DOCKER_HOST="unix://${XDG_RUNTIME_DIR}/podman/podman.sock"
supabase db pull
- pg-delta Edge Runtime helper cannot read the CLI-generated
supabase/.temp/pgdelta/pgdelta-target-ca.crt file and exits with EACCES
Crash report ID
No response
Docker and service versions
Additional context
The following is AI slop
This is an SELinux labeling issue, rather than a Unix file-permission issue. As a scoped local workaround, relabeling only the ignored CLI temporary directory lets the local database initialization progress past an analogous pg_sodium secret-read failure:
chcon -Rt container_file_t supabase/.temp
For db pull specifically, the documented alternative diff engine also succeeds:
supabase db pull --diff-engine migra
A separate supabase start attempt encountered the same class of failure for a CLI-generated file under supabase/.temp/start-secrets/.../secret-0, bind-mounted read-only as /etc/postgresql-custom/pgsodium_root.key. This suggests the problem is shared handling of CLI-owned temporary bind-mount sources; the db pull reproduction above is the smallest observed case.
Could the CLI use an SELinux-compatible mount strategy for its own generated temporary files when using Podman, or avoid host bind mounts for this certificate material? The scope should remain limited to CLI-created files rather than applying a label change to arbitrary project source directories.
Related but not duplicates:
Affected area
Database
Supabase CLI version
v2.110.0
Operating system
Fedora 44
Installation method
npm
Command
Actual output
Expected behavior
supabase db pullshould complete with its default diff engine when the CLI is connected to a rootless Podman Docker-compatible socket on an SELinux-enforcing host. It should not require the user to relabel CLI-generated temporary artifacts manually.Steps to reproduce
systemctl --user start podman.socket, ensure it is rootlessexport DOCKER_HOST="unix://${XDG_RUNTIME_DIR}/podman/podman.sock"supabase db pullsupabase/.temp/pgdelta/pgdelta-target-ca.crtfile and exits withEACCESCrash report ID
No response
Docker and service versions
Podman `5.8.4`Additional context
The following is AI slop
This is an SELinux labeling issue, rather than a Unix file-permission issue. As a scoped local workaround, relabeling only the ignored CLI temporary directory lets the local database initialization progress past an analogous pg_sodium secret-read failure:
For
db pullspecifically, the documented alternative diff engine also succeeds:A separate
supabase startattempt encountered the same class of failure for a CLI-generated file undersupabase/.temp/start-secrets/.../secret-0, bind-mounted read-only as/etc/postgresql-custom/pgsodium_root.key. This suggests the problem is shared handling of CLI-owned temporary bind-mount sources; thedb pullreproduction above is the smallest observed case.Could the CLI use an SELinux-compatible mount strategy for its own generated temporary files when using Podman, or avoid host bind mounts for this certificate material? The scope should remain limited to CLI-created files rather than applying a label change to arbitrary project source directories.
Related but not duplicates:
DOCKER_HOSTworking and SELinux enforcing.