RLS Error on Storage INSERT for 'anon' role, even with a WITH CHECK (true) policy

[ManorovG]

Bug report

Hello,

I am experiencing a persistent "new row violates row-level security policy" error when trying to upload a file to Storage.

Context:

• The upload happens immediately after a supabase.auth.signUp() call.
• I have "Confirm email" enabled, so the user making the request is in the anon role.
• The file upload and database insert operations are succeeding, but the client-side code still receives the RLS error.

Troubleshooting Done:

1. I created a PERMISSIVE policy for the anon role to INSERT on my 'documents' bucket.
2. The error continued, so for debugging, I changed the policy's WITH CHECK expression to simply true.
3. The RLS violation error still occurs, even with the WITH CHECK (true) policy.

A query on pg_policies shows that this is the only policy on storage.objects, and it is configured correctly. There are also no custom triggers. It seems the RLS policy is not being respected.

Could you please investigate why my project might be behaving this way?

My Project Ref is: [qrtywghupjaljhxblpcd]

[allenarduino]

Hey @ManorovG, just adding a thought here that might help with debugging.

It could be two things happening at once:

When you call signUp with email confirmation enabled, the user is still treated as anon until they confirm their email. At the same time, Supabase Storage also checks bucket settings (like whether the bucket is public), not only RLS policies.

So even if you set up a policy that gives the anon role full permission to add files into the storage objects table, without placing any conditions or restrictions on what they can insert, the upload can still fail if the bucket itself is not configured to allow writes from anonymous users.

The request can still fail if the bucket isn’t public or doesn’t allow writes from anon.

A couple of quick checks that might help narrow it down:

1. Try an upload with the service role key → if that works, RLS is fine.
2. Check if the documents bucket is marked public.
3. Test again after confirming the user’s email so they come in as authenticated.

That should help figure out if this is really RLS being ignored, or if Storage is rejecting anon uploads earlier in the flow.

[GaryAustin1]

Also make sure you don't have upsert option set for the upload. If so then you need to meet select policy.

[Hallidayo]

Hi everyone, I'll move this over a discussion as seems more debugging than an issue.

[marinengg]

Hi, I am having a similar error. Is this resolved yet what was the final solution. Please share. Thank you.
The following was my issue:
Storage uploads to bucket candidate-cvs fail with HTTP 400, response body {"statusCode":"403","error":"Unauthorized","message":"new row violates row-level security policy"}.
This is NOT a policy misconfiguration — exhaustively ruled out:

INSERT policies exist for anon, authenticated, public (WITH CHECK true), AND supabase_storage_admin (WITH CHECK bucket_id='candidate-cvs'). Upload still fails.
Postgres logs show the failing insert runs as USER supabase_storage_admin (rolbypassrls=false), COMMAND INSERT, status 42501.
Bucket tested empty, and as both private and public. Tested both raw-body and multipart/form-data uploads. Identical failure every time.
Standard anon POST to /storage/v1/object/candidate-cvs/.pdf, ~830KB PDF, valid anon JWT (role:anon).
A direct SQL insert into storage.objects as anon succeeds, but real Storage uploads fail.

A policy explicitly covering supabase_storage_admin still being violated indicates the Storage service's role/RLS handling is malfunctioning for this project.

[GaryAustin1]

You would not need policies for storage_admin and they would make no difference for API calls.
You are either not the role you think you are, you are needing a select policy if doing upsert, or your policies are not on storage.objects but on the bucket table. There might be other things but those are what come to mind.

Check your storage logs also.

There is no known bug in this process.