The `postgres` role doesn't have access to newly created tables?

Describe the bug

Confused by this, but if I create a new table in the UI, and then try to SELECT or INSERT into it with the “Connection Pooling” connection (using the postgres role) I get the following error:

error: permission denied for table test

This happens even without enabling row-level access control.

Expected behavior

I thought the postgres role would have permissions to all objects by default? (Especially ones created through the dashboard.)

None of the creating tables examples have any extra permissions-granting steps. When I first created the database I restored some data from a previous backup, might that have messed up permissions somehow? Very unclear.

Am I doing something wrong?

[ydennisy]

Hey @kiwicopple I was wondering if you had a chance to add more docs for resetting permissions?

[ianstormtaylor]

@kiwicopple Thank you, that’s helpful!

I think you’re right that it was due to the restore. What I did was pipe pg_dump | psql originally to load ~50 large tables from a previous database provider I was using into Supabase when I created the project. But there might have been some logic in the dump that changed how public schema permissions were setup.

I looked over the existing grants:

And it does seem like all the imported tables didn’t get permissions extended to anyone but postgres—which would likely be a problem as soon as I start trying to use the PostgREST API I’d assume.

And I found this file too which was helpful. I think specifically these lines might restore the default behavior for the future:

https://github.com/supabase/supabase/blob/d1d6278913f5a752253a3d47a0d4adabd3bfaf7a/docker/volumes/db/init/00-initial-schema.sql#L37-L43

I think the biggest thing that would have helped me (not knowing much about granting privileges in PG before running into this) was a page in the docs describing each of the roles that Supabase uses. I found reference in different places to many different names:

• anon
• authenticated
• service_role
• postgres
• supabase_admin
• supabase_auth_admin
• supabase_storage_admin
• dashboard_user
• pgbouncer
• authenticator

Explaining what they are for, and what permissions they need to have to work properly. (Also potentially eliminating some of them, because it feels like a lot, but obviously that’s not my call.)

---

Follow up question: Do I need to grant those tables, functions, sequences privileges to all of these grantees: anon, authenticated, dashboard_user, postgres, service_role, supabase_admin?