RLS Error Uploading to Supabase Storage Bucket Using Service Role Key

[kungfucode]

Hi Supabase team,

I'm encountering an RLS error when trying to upload audio files to a Supabase Storage bucket (audio) from my backend server using the SUPABASE_SERVICE_ROLE_KEY. The upload fails with the following message:

StorageApiError: new row violates row-level security policy status: 400

Here’s what I’ve verified:
I'm using the @supabase/storage-js SDK from a Node backend (running on Replit)

createClient(SUPABASE_URL, SUPABASE_SERVICE_ROLE_KEY) is used server-side

The file is a valid .webm with correct content-type

The bucket is audio, and the upload target is cleanly formatted

Replit support confirmed:
→ The Authorization header is not being overwritten
→ The service role key is being passed properly

My RLS policy on storage.objects:
CREATE POLICY "Service role can upload audio files" ON storage.objects FOR INSERT TO service_role WITH CHECK (bucket_id = 'audio');

Even with this policy in place, the upload still fails unless I fully disable RLS on the bucket. Everything I’ve read suggests that the service role should either bypass RLS or this policy should be sufficient.

Is there any known issue where:

The service role doesn’t bypass RLS in Storage?

Storage policies require additional conditions?

Supabase fails to detect service role when using @supabase/storage-js directly in a Node backend?

Let me know what else I can try — happy to share more context if needed.

Thanks in advance!

[GaryAustin1]

The service role does bypass RLS.
Check your API Gateway log to see if the role of the storage operation is service_role.

It is common for users to not create a separate service_role client in their server side code and then a user session will get into that client instead of the default from the apikey. You must have a separate "admin" client and not also use the same client for user access.

There is one other odd case but I'll have to see if I can find it where there is a grant error or something odd that I can't recall than manifests as an RLS error. The most common case is the one above.

https://supabase.com/docs/guides/troubleshooting/performing-administration-tasks-on-the-server-side-with-the-servicerole-secret-BYM4Fa

Edit:
Still have not found it. But have you run any SQL that modified the storage schema grants? Any triggers added to storage?

[moracabanas]

Sorry to reuse or bring this question back.

I was trying to apply some RBAC authorization policies to my uploads, based on Supabase RBAC Docs

Then when I dropped my custom policies to update their checks and behabiour, I got locked.

DROP POLICY "Authorized users can upload files" ON storage.objects;
DROP POLICY "Authorized users can view files"   ON storage.objects;
DROP POLICY "Authorized users can update files" ON storage.objects;
DROP POLICY "Authorized users can delete files" ON storage.objects;

Now using Supabase Studio I cannot upload to any bucket, public/private, newly created or whatever.

The service role is not bypassing RLS anymore and I got stuck.

I try to upload a file to my bucket from supabase studio, the progress bar reach 100% and it just disappears giving a 403 error with the message "new row violates row-level security policy"

I fear to broke storage policies and now I don't know to restore the default service key RLS bypass policies.

[moracabanas]

Thanks for the reply, I do not have enough expertise to check all default grants for storage nor recreate the default ones. How could I check for them so I can expose the issues behind?
I didn't expect to brake this messing with just RLS policy, those drops were the only destructive commands I wrote related with storage

[GaryAustin1]

Check the API Gateway and Storage logs to see if more info.
I doubt this is RLS if the dashboard does not work.
You could also try select * from storage.objects; in the SQL editor. Then change to service_role if it runs as Postgres with the impersonation button in bottom right.

[moracabanas]

No problem on the SQL editor with service key

When I try to upload a file ton supabase studio, and it just dissapear, I check the API Gateway logs and I get this 403 error

{
  "event_message": "POST | 403 | ****IP****** | 975d1d96ab9d6671 | https://<PROJECT>.supabase.co/storage/v1/upload/resumable | Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/139.0.0.0 Safari/537.36 Edg/139.0.0.0",
  "id": "55d9ea0d-c3af-4798-9ee2-2a8afd32548d",
  "metadata": [
    {
      "load_balancer_experimental_routing": null,
      "load_balancer_geo_aware_info": [],
      "load_balancer_redirect_identifier": null,
      "logflare_worker": [
        {
          "worker_id": "NKAR24"
        }
      ],
      "request": [
        {
          "cf": [
            {
              "asOrganization": "Jazztel Triple Play Services",
              "asn": 12479,
              "botManagement": [
                {
                  "corporateProxy": false,
                  "detectionIds": [],
                  "ja3Hash": "705e46197728c40517b736ff242daaeb",
                  "ja4": "q13d0312h3_55b375c5d22e_5a06198afb93",
                  "ja4Signals": [
                    {
                      "browser_ratio_1h": 0.4150213599205,
                      "cache_ratio_1h": 0.3215671479702,
                      "h2h3_ratio_1h": 1,
                      "heuristic_ratio_1h": 0.001120905042626,
                      "ips_quantile_1h": 0.9999760389328,
                      "ips_rank_1h": 8,
                      "paths_rank_1h": 6,
                      "reqs_quantile_1h": 0.9999760389328,
                      "reqs_rank_1h": 8,
                      "uas_rank_1h": 20
                    }
                  ],
                  "jsDetection": [
                    {
                      "passed": false
                    }
                  ],
                  "score": 99,
                  "staticResource": false,
                  "verifiedBot": false
                }
              ],
              "city": "Logroño",
              "clientAcceptEncoding": "gzip, deflate, br",
              "clientTcpRtt": null,
              "clientTrustScore": 99,
              "colo": "MAD",
              "continent": "EU",
              "country": "ES",
              "edgeRequestKeepAliveStatus": 1,
              "httpProtocol": "HTTP/3",
              "isEUCountry": null,
              "latitude": "42.46667",
              "longitude": "-2.45000",
              "metroCode": null,
              "postalCode": "26001",
              "region": "La Rioja",
              "regionCode": "LO",
              "requestPriority": null,
              "timezone": "Europe/Madrid",
              "tlsCipher": "AEAD-AES128-GCM-SHA256",
              "tlsClientAuth": [
                {
                  "certPresented": "0",
                  "certRevoked": "0",
                  "certVerified": "NONE"
                }
              ],
              "tlsClientCiphersSha1": "3HTt3+R/6BL3zeALJDSq0pR1yOQ=",
              "tlsClientExtensionsSha1": "MfEV0ekN0gVfwPm1Qa1zY62aWPI=",
              "tlsClientExtensionsSha1Le": "CABurLinZPnRPJGnrT/XNtIvybM=",
              "tlsClientHelloLength": "1991",
              "tlsClientRandom": "mYqy7Km6YOqHu0hybsoym7eo85QKWbUPVU/mwt/+dEk=",
              "tlsExportedAuthenticator": [
                {
                  "clientFinished": "b8b3cf824a3b8692f1ffe3c7e93dc8e99a00a8b4ddad176e20e8500c2971a70d",
                  "clientHandshake": "01adaac4220dcdfae3fe50ae76ebb240fa26470a5bc09c8ce1be3042ac421601",
                  "serverFinished": "66b3c0f1af8c7f8c1a7d04754b7615617a2ed6e9ce39ffd4c9eef0d490d2ab02",
                  "serverHandshake": "80e56e58f6ac97bdde93f87e47f65825cb676ea373c88a17b2d5f152737b6af1"
                }
              ],
              "tlsVersion": "TLSv1.3",
              "verifiedBotCategory": null
            }
          ],
          "headers": [
            {
              "accept": "*/*",
              "cf_cache_status": null,
              "cf_connecting_ip": "<IP>",
              "cf_ipcountry": "ES",
              "cf_ray": "975d1d96ab9d6671",
              "content_length": "2172364",
              "content_location": null,
              "content_range": null,
              "content_type": "application/offset+octet-stream",
              "date": null,
              "host": "<PROJECT>.supabase.co",
              "prefer": null,
              "range": null,
              "referer": "https://supabase.com/",
              "sb_gateway_mode": null,
              "sb_gateway_version": null,
              "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/139.0.0.0 Safari/537.36 Edg/139.0.0.0",
              "x_client_info": null,
              "x_forwarded_host": null,
              "x_forwarded_proto": "https",
              "x_forwarded_user_agent": null,
              "x_kong_proxy_latency": null,
              "x_kong_upstream_latency": null,
              "x_real_ip": "<IP>"
            }
          ],
          "host": "<PROJECT>.supabase.co",
          "method": "POST",
          "path": "/storage/v1/upload/resumable",
          "port": null,
          "protocol": "https:",
          "sb": [
            {
              "apikey": [
                {
                  "authorization": []
                }
              ],
              "auth_user": null,
              "jwt": []
            }
          ],
          "search": null,
          "url": "https://<PROJECT>.supabase.co/storage/v1/upload/resumable"
        }
      ],
      "response": [
        {
          "headers": [
            {
              "cf_cache_status": "DYNAMIC",
              "cf_ray": "975d1d98661d6671-MAD",
              "content_length": "42",
              "content_location": null,
              "content_range": null,
              "content_type": "text/plain;charset=UTF-8",
              "date": "Wed, 27 Aug 2025 16:58:46 GMT",
              "sb_gateway_mode": "direct",
              "sb_gateway_version": "1",
              "transfer_encoding": null,
              "x_kong_proxy_latency": null,
              "x_kong_upstream_latency": null,
              "x_sb_error_code": null
            }
          ],
          "origin_time": 211,
          "status_code": 403
        }
      ]
    }
  ],
  "timestamp": 1756313926423000
}

[GaryAustin1]

I see now it does not have service_role option, not that I think the dashboard storage UI uses that.

Nothing in the storage logs?

You could run this to see if all the API roles and postgres have access to the storage.objects table.

SELECT grantee, privilege_type
FROM information_schema.table_privileges
WHERE table_schema = 'storage' AND table_name = 'objects';

You may need to make a support request.

[moracabanas]

In storage logs everything was 200, it was 403 on API Gateway

Running your purposed query returns this:

grantee	privilege_type
anon	INSERT
anon	SELECT
anon	UPDATE
anon	DELETE
anon	TRUNCATE
anon	REFERENCES
anon	TRIGGER
authenticated	INSERT
authenticated	SELECT
authenticated	UPDATE
authenticated	DELETE
authenticated	TRUNCATE
authenticated	REFERENCES
authenticated	TRIGGER
service_role	INSERT
service_role	SELECT
service_role	UPDATE
service_role	DELETE
service_role	TRUNCATE
service_role	REFERENCES
service_role	TRIGGER
postgres	INSERT
postgres	SELECT
postgres	UPDATE
postgres	DELETE
postgres	TRUNCATE
postgres	REFERENCES
postgres	TRIGGER

Now I had to hit "change database password" button on database settings to get a new password and then inspect the whole database to seek some clues on internal tables.

After that, one hour later the Logs section is missing any information. I guess because the new db password didn't propagated yet on supabase big infra.

I guess better to 1:1 migrate this project to a new one as we were just scafolding the whole RBAC, tables, functions, edge functions and RLS policies.

I will also seek support following your recommendation, and if you get a clue, you are welcome!

Thanks

[moracabanas]

I found the issue, we had a trigger on storage to execute a function to process files. The function wasn't fully functinal, failing.
So when a file is added, the function execution fails, and then the file is not present anymore in the storage. Removing the trigger fixed the issue.

The most confusing part, is the all errors related to this were comming in a form of RLS issue, pointing me in the wrong direction.

Another member of the team created the trigger to work on the function that process files uploaded. I wasn't aware of that, and also I didn't think that if a trigger(after create) fails to execute a function, the file is not even added.

So be careful about triggers applied over supabase internal schemas, ther could be some side effects like this, more difficult to track. I will try to use a webhook instead.

Anyways thanks for the help and attentiont provided ✌️