Storage RLS rejects all uploads — auth.uid() NULL for ES256 JWTs (project rynswrhabeobtyjthpto)

[Krishna-Agrawall]

Support ticket already open: SU-435660. Posting here too since Free plan support has no guaranteed SLA and this blocks a real feature.

Symptom: Every authenticated Storage upload fails with "new row violates row-level security policy" (403, AccessDenied) — on ALL buckets, reproduced identically on two separate buckets with standard "own folder" RLS policies.

Already ruled out:

RLS policy SQL is correct (verified live via supabase db query): bucket_id = 'X' AND auth.uid()::text = (storage.foldername(name))[1]
Table grants correct (has_table_privilege checks pass for INSERT/UPDATE/SELECT)
Function EXECUTE grants correct on auth.uid() and storage.foldername()
Same session token works fine via PostgREST (.from('table').select() succeeds)
Full project restart (Dashboard → Settings → General) — no change
Key detail: the session JWT is signed with ES256 (asymmetric signing key), header {"alg":"ES256","kid":"610546af-3178-4161-ad93-4abcd815a86a"}. PostgREST verifies it fine. Storage does not — every storage.objects RLS check referencing auth.uid() behaves as if it's NULL, consistent with Storage failing to verify this ES256-signed token while PostgREST verifies it correctly.

Anyone else on ES256 signing keys seeing Storage RLS fail like this? Or know if Storage has a known gap with asymmetric JWTs?

[GaryAustin1]

Asymmetric keys work with storage.

Are you getting storage errors or just RLS blocking? Did you check the storage log?

How are you determining auth.uid() is null?
How do you know this is related to asymmetric JWTs versus calling with wrong session?

Do you have the needed RLS policies for the type of upload you are doing? INSERT, SELECT, UPDATE?

[Krishna-Agrawall]

Found it — and it was on our end, not a Supabase bug. Great question, that was exactly it.

We had NO SELECT policy at all on storage.objects for either bucket (only INSERT/UPDATE/DELETE). Our original migration reasoned "bucket is public, reads go through the public URL, no SELECT policy needed" — true for a browser hitting the public URL directly, but upload(..., { upsert: true }) needs to check whether an object at that path already exists first (an authenticated SELECT against storage.objects, subject to RLS) before deciding insert vs. update. With zero SELECT policy, that internal existence check always evaluated to "not visible", and the whole upsert failed closed with the RLS message — even though our INSERT policy itself was completely correct.

Confirmed by testing: { upsert: false } (no existence check needed) succeeded immediately even before the fix. Added a SELECT policy scoped to each user's own folder (same pattern as the existing insert/update/delete policies) and upsert: true now works end-to-end.

Thanks for pushing on the actual error/logs instead of letting me keep chasing the ES256 theory — that's what got us here. Marking this solved.

[cekuu35]

The error text is identical for two very different causes, and your own evidence points away from the one you're leaning toward. Worth separating them before assuming an ES256 gap.

"new row violates row-level security policy" on a Storage upload is very often not the INSERT check failing — it's the SELECT after it. Storage runs INSERT ... RETURNING *, and if no SELECT policy on storage.objects covers the row you just inserted, the RETURNING is filtered out and the whole statement surfaces as exactly this violation. Your has_table_privilege check doesn't catch this, because grants and RLS policies are different layers: INSERT/SELECT/UPDATE grants can all pass while a SELECT policy is simply absent. This is the single most common cause of this precise 403, and nothing in your "already ruled out" list actually rules it out.

Test it first, because it's decisive and takes a minute — add a SELECT policy mirroring your INSERT one:

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

If uploads start working, auth.uid() was never NULL — it resolved correctly on both the INSERT check and this SELECT — and the ES256 theory is dead.

If it still fails, then measure auth.uid() directly instead of inferring it. Right now "auth.uid() is NULL" is a hypothesis, and Gary's question is the right one to press on. You can turn it into a fact by making the policy encode what it sees. Temporarily:

alter policy "<your insert policy>" on storage.objects
with check ( (storage.foldername(name))[1] = coalesce(auth.uid()::text, 'NULL_UID') );

Then upload one file into a folder literally named NULL_UID. If that upload succeeds, auth.uid() is confirmed NULL in the Storage path while PostgREST resolves it — which is the real signature of a token Storage isn't verifying. At that point you have a reproducible artifact for SU-435660 instead of a symptom.

One mechanism that fits the "PostgREST fine, Storage not" split specifically: the two paths don't have to resolve the JWT the same way. auth.uid() just reads request.jwt.claims off the connection; if that claim is populated for the PostgREST path but empty on the connection Storage uses for the RLS check, auth.uid() reads NULL there and only there. I wouldn't assert that's what's happening on your project — the two experiments above tell you whether you're even in that territory before support has to weigh in.