Supabase: new row violates row-level security policy.

What you see

A logged in user uploads a file to Supabase Storage, or inserts a row, and gets "new row violates row-level security policy".

The storage bucket exists. You may have written the policy yourself and it looks correct. You can see it in your migration file.

Why it happens

This error means RLS checked the new row and no policy allowed it. That can happen for four different reasons, and only one of them is a wrong policy.

• The policy was never applied. A migration created the bucket, but its storage.objects policies never applied. Production can be several migrations behind your code.
• The policy does not match the row. The insert check compares the wrong column, or the file path does not match what the policy expects.
• The row cannot pass its own check. For example, the row that makes you a member of a group can never pass a "you must be a member" check.
• The token is not reaching Storage. On one project, Storage was not applying the user's JWT, while PostgREST queries with the same token worked. Editing the policy cannot fix that.

The fix, step by step

Step 1. Check what policies really exist. Do not trust your migration file. Ask the live database:

select policyname, cmd
from pg_policies
where schemaname = 'storage' and tablename = 'objects';

Every policy you expect must be in the result. For a normal table, change the schema and table name.

Step 2. If policies are missing, rerun the migration. Write migrations as idempotent SQL so you can safely rerun them. The service role key cannot run DDL, so use the SQL editor, a Management API token or the database password.

Step 3. Check the policy against the row you are writing. A typical upload policy only allows files in the user's own folder:

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

With this policy, a path like uploads/USER_ID/photo.jpg passes and uploads/photo.jpg fails. Compare your real upload path to the check.

Step 4. For tables, check the grant too. RLS policies need table grants as well. If the role lacks INSERT, or lacks SELECT when you read the row back, fix that first.

Step 5. If the row can never pass its own check, use a function. Do creation and invite acceptance through SECURITY DEFINER functions instead of loosening the insert policy. Put membership checks in a helper such as is_member(group_id), so the members table policy does not query itself and recurse.

Step 6. If the policy is right and Storage still refuses, test the token. Send the same user token to a normal PostgREST table query. If that works and Storage still fails, the token is not being applied to Storage. Route uploads through a server function that verifies the token, then writes with the service role key:

const { data: { user }, error } = await sb.auth.getUser(bearerToken);
if (error || !user) return { statusCode: 401, body: 'Unauthorized' };

const path = user.id + '/' + fileName;
const { error: upErr } = await admin.storage
  .from('uploads').upload(path, fileBuffer, { contentType });
if (upErr) return { statusCode: 500, body: upErr.message };

Here admin is a client made with the service role key, which stays on the server. The client POSTs the file or a data URL to this function.

Step 7. Check every write. supabase-js returns errors as values instead of throwing. An RLS refusal can even return no error and no row. Chain .select() and confirm a row came back.

How to prevent it

• Probe the live schema, including policies, before writing code against it.
• When a policy looks right but fails, test the same token against PostgREST before rewriting policies.
• Verify by impersonating a stranger's token and confirming they see zero rows.

Related traps

• Every insert returns 400. A broken trigger that references a missing column fails every insert. Inspect triggers before touching RLS.
• Anonymous sign-in. On a shared project, anonymous users get the authenticated role and every policy written for it.
• Free projects pause. After about 7 idle days, every call fails until you resume the project.

Keep reading.