Issues creating application RLS policies on storage.objects

[chrisfab01]

We are trying to create application RLS policies on storage.objects in a newly created hosted Supabase project.

The SQL Editor session reports:

• current_user = postgres
• session_user = postgres
• postgres is not a superuser
• storage.objects is owned by supabase_storage_admin
• postgres is not a member of supabase_storage_admin
• postgres cannot SET ROLE to supabase_storage_admin
• RLS is already enabled on storage.objects

We only need to execute CREATE POLICY ... ON storage.objects; we are not trying to alter the Storage table, change its owner, disable/enable RLS, or modify the Storage schema.

Supabase's Storage documentation documents CREATE POLICY ... ON storage.objects, and the schema-restriction guidance states that creating RLS policies on storage.objects remains permitted.

Under the current hosted-project permission model, what is the officially supported and reproducible way to execute CREATE POLICY on storage.objects?

Specifically:

1. Should the SQL Editor postgres role normally have indirect ownership authority over storage.objects?
2. Is the absence of that authority on a newly created project expected?
3. Does the SQL Editor or another supported Supabase execution surface mediate Storage policy creation through supabase_storage_admin?
4. Is the Storage Policies UI the required execution path?
5. If the UI is required, is there a supported SQL/migration-equivalent mechanism suitable for reproducible database provisioning?
6. Is SET ROLE supabase_storage_admin intentionally unavailable to postgres?

We do not want to grant ourselves membership in supabase_storage_admin, change table ownership, or otherwise work around Supabase's privilege model. We want to use the officially supported mechanism.

[cekuu35]

Short version: on a hosted Supabase project, plain CREATE POLICY ... ON storage.objects is still permitted ? the thing that was blocked (April 2025) is ALTER TABLE storage.objects, because the table is owned by supabase_storage_admin and your postgres role isn't. Since RLS is already enabled by default, you'll hit this only if an ALTER TABLE (or ENABLE/DISABLE ROW LEVEL SECURITY) line is executing before your CREATE POLICY in the same script. Drop that line and the CREATE POLICY runs fine under postgres.

To your specific questions:

• 1 & 2. Your postgres role normally has authority to create RLS policies on storage.objects, but not to alter the table. So the "absence of authority" you're seeing is almost certainly the ALTER TABLE line, not policy creation. It's expected that postgres isn't the table owner.
• 3 & 4. Two supported paths: the Storage ? Policies UI (which writes the policy for you using an already-permitted path), or CREATE POLICY directly in the SQL editor / migration. Both work; a migration that only contains CREATE POLICY for storage.objects applies cleanly via supabase db push.
• 5. Yes ? a migration file containing only CREATE POLICY statements for storage.objects is supported and reproducible. That's the migration-equivalent path.
• 6. SET ROLE supabase_storage_admin being unavailable to postgres is expected and intentional; you don't need it to create policies. You're not supposed to grant yourself membership in that role.

Can you paste the exact SQL you're running? I'd bet it includes an ALTER TABLE storage.objects ... near the top (a common AI-generator copy-paste from older storage tutorials). A policy-only script like this applies cleanly today:

create policy "users read own files"
on storage.objects for select
to authenticated
using (
  bucket_id = 'avatars'
  and (storage.foldername(name))[1] = (select auth.uid()::text)
);

If you're still blocked, reproduce it in the SQL editor as postgres with just the CREATE POLICY (no ALTER TABLE) and share the exact error ? but I'd expect it to succeed.

[omerfarooqBM]

Your diagnostics are all accurate, but they describe a restriction that doesn't actually gate CREATE POLICY. The short answer: run the bare CREATE POLICY statement as postgres in the SQL Editor — that is the officially supported path, and it works despite everything on your checklist being true.

Why ownership isn't the blocker here

Upstream Postgres does say "You must be the owner of a table to create or change policies for it." So your inference is reasonable — it's just that the hosted platform carves this case out deliberately: postgres is allowed to create policies on storage.objects while being blocked from ALTER TABLE on it. Two Supabase maintainers have stated this directly:

"You should not need to be the owner of storage schema tables. They are protected. You can add RLS and read/insert/update them thru SQL or the storage API calls."
— GaryAustin1, discussion #38474

"Due to recent permission changes on postgres platform, altering tables in storage schema is no longer possible."
— sweatybridge, discussion #36611 (marked as the answer)

So postgres not being a member of supabase_storage_admin, and not being able to SET ROLE to it, is expected and isn't what stops you. The restriction is scoped to schema/table modification, not policy creation.

What's most likely actually failing

You said you're not trying to ALTER TABLE — but the usual cause of this exact situation is that an ALTER TABLE is present anyway, inherited from a migration or a copied snippet:

alter table storage.objects enable row level security;  -- ❌ fails: must be owner of table objects
create policy "..." on storage.objects ...;             -- never runs

Two things make this bite harder than it looks:

• RLS is already enabled by default on storage.objects, so that line is redundant even when it doesn't error.
• The SQL Editor runs a multi-statement script as one batch, so the failed ALTER TABLE aborts the transaction and takes the CREATE POLICY after it down with it. The error you see names the ALTER TABLE problem while the statement you care about never executed.

Drop the ALTER TABLE line and run only:

create policy "authenticated can upload to own folder"
on storage.objects
for insert
to authenticated
with check (
  bucket_id = 'my-bucket'
  and (storage.foldername(name))[1] = auth.uid()::text
);

Note with check (not using) for INSERT. If you also read the rows back — including implicitly, since INSERT ... RETURNING applies SELECT policies to the returned rows — add a matching for select policy, or the insert appears to fail for RLS reasons that have nothing to do with your insert policy.

If you're going through the CLI

supabase db push applies migrations as postgres, so the same rule applies: remove the ALTER TABLE ... ENABLE ROW LEVEL SECURITY line from the migration file. If that migration was already recorded, realign history with:

supabase migrations repair --status applied <version>

To answer your actual question directly

There is no special role, SET ROLE, or ownership transfer step in the supported path — that's why the docs show a plain CREATE POLICY ... ON storage.objects with no prerequisites. The Dashboard's Storage → Policies UI issues the same statement; it isn't a privileged escape hatch, so if the bare CREATE POLICY genuinely fails for you, the UI will fail identically.

That last part is the useful test: run only the CREATE POLICY statement, nothing before it, and paste the verbatim error if it still fails. If a lone CREATE POLICY ... ON storage.objects errors as postgres on a fresh hosted project, that's outside the documented permission model and worth pursuing on your ticket (SU-…) as a provisioning problem rather than a usage question.

[cekuu35]

Storage policies are separate from table RLS. The supabase.storage API uses /object/ endpoint which checks storage.objects policies, NOT your table policies.

Required policies for bucket my-bucket:

-- Allow authenticated uploads
CREATE POLICY "auth_upload" ON storage.objects
  FOR INSERT TO authenticated
  WITH CHECK (bucket_id = 'my-bucket');
-- Allow authenticated full access
CREATE POLICY "auth_full" ON storage.objects
  FOR ALL TO authenticated
  USING (bucket_id = 'my-bucket');
-- Allow public reads (if bucket is public)
CREATE POLICY "public_read" ON storage.objects
  FOR SELECT TO anon
  USING (bucket_id = 'my-bucket');

Verify bucket exists and is public/private correctly:

SELECT id, name, public FROM storage.buckets WHERE id = 'my-bucket';

The service_role key works because it bypasses ALL RLS — that's expected behavior.

Free Storage + RLS audit: https://github.com/cekuu35/supabase-rls-leak-demo