The restore that broke logins

A restore without ownership, and the confusing pair of errors it produces.

FromSelf-Hosted Platform: k3s on Hetzner

A cutover restore used the no-owner option to avoid role errors. It worked, and the next start of the auth service failed on a missing schema, and logins failed on a missing table. Both existed. They belonged to the wrong role.

sequenceDiagram
  participant R as Restore, no owner
  participant DB as Postgres
  participant A as Auth service
  R->>DB: recreate auth schema, owned by the restore role
  A->>DB: run migrations on start
  DB-->>A: no schema has been selected to create in
  A-->>A: logins fail: relation users does not exist

The restore script now re-applies schema ownership after every restore, idempotently, and the fix was applied preventively to the two sibling projects:

SQL

ALTER SCHEMA auth    OWNER TO supabase_auth_admin;
ALTER SCHEMA storage OWNER TO supabase_storage_admin;

Takeaway

Skipping ownership is not free; it moves the error to the first process that needs it.