Hosted project cannot CREATE/DROP RLS policies on storage.objects as postgres — SQLSTATE 42501

[fatiboams]

We are commissioning a reviewed security migration on hosted Supabase project gvgjdhvdxyivlhnkquek.

Read-only catalog inspection shows:

• storage.objects owner = supabase_storage_admin
• SQL Editor current_user / session_user = postgres
• postgres is not a member of supabase_storage_admin
• postgres is not superuser
• application data/schema are otherwise healthy

The migration needs to DROP/CREATE RLS policies on storage.objects.

Based on Supabase’s platform restriction announcement, creating RLS policies and triggers on storage.objects should remain supported even though Storage objects remain owned by supabase_storage_admin.

Our current executor cannot do this and would fail with SQLSTATE 42501: must be owner of table objects.

We do not want to alter ownership of the Storage schema or grant ourselves the managed supabase_storage_admin role.

Please confirm whether this project’s database permissions are in the expected hosted-platform state and advise the supported method to create/drop RLS policies on storage.objects.

No live migration or Storage mutation has been performed.

Our hosted project’s storage.objects table is owned by supabase_storage_admin, while SQL Editor runs as postgres. We need the supported way to DROP POLICY / CREATE POLICY on storage.objects for a reviewed RLS migration without altering managed ownership. What is the correct supported execution path?

[k1ng-arthur]

I think you already messaged the discord and we resolve it that you can create policies from the SQL editor for storage.buckets. Here is a doc with some examples https://supabase.com/docs/guides/storage/security/access-control