RLS Enabled on auth.users Table Blocking User Signups

[lapidus20-png]

Hello Supabase Support,

I'm experiencing a critical issue with my project (ID: fldkqlardekarhibnyyx) where user signups are failing.

Problem:

User signups fail with error: "new row violates row-level security policy for table 'users'"
The auth.users table has Row Level Security (RLS) enabled
I cannot disable RLS because I don't have owner permissions (error: "must be owner of table users")
What I've verified:

RLS is enabled on auth.users (system table)
I cannot modify this table - it's owned by supabase_auth_admin role
My application's public.users table has correct RLS policies
This appears to be a project configuration issue
Expected behavior:
The auth.users system table should NOT have RLS enabled by default, as this prevents Supabase's own authentication system from creating users.

Request:
Could you please disable RLS on the auth.users table in my project, or advise on how to resolve this configuration issue?

Error details:

new row violates row-level security policy for table "users"
Thank you for your help!

[bistrachilikova]

Have you tried disabling this via a migration?

[GaryAustin1]

This is most likely you have an auth.users trigger function or auth hook that is trying to access your PUBLIC.users table.
If so you may need a security definer trigger function.

[tranducluong182]

Hi Supabase Support team,

Additional diagnostic update on ticket SU-409988 (project ref: yrygiwoqfzzkkuriobqu).

I ruled out a common alternate cause (auth trigger function not being SECURITY DEFINER) by checking directly:

SELECT proname, prosecdef FROM pg_proc WHERE proname = 'handle_new_auth_user';
-- Result: prosecdef = true (already correctly SECURITY DEFINER)

So the issue is not on the trigger/function side. This confirms the root cause is RLS enabled on auth.users itself (owned by supabase_auth_admin) with zero policies, which I cannot disable due to insufficient ownership permissions (ERROR: 42501: must be owner of table users).

This is still actively blocking all new user signups in production. Could someone with internal access please disable RLS on auth.users for this project (or confirm supabase_auth_admin's BYPASSRLS status hasn't been affected)?

Happy to provide further diagnostics if needed.

Thanks,

[tranducluong182]

Hi Supabase Support team,

Additional diagnostic update on ticket SU-409988 (project ref: yrygiwoqfzzkkuriobqu).

I ruled out a common alternate cause (auth trigger function not being SECURITY DEFINER) by checking directly:

SELECT proname, prosecdef FROM pg_proc WHERE proname = 'handle_new_auth_user';
-- Result: prosecdef = true (already correctly SECURITY DEFINER)

So the issue is not on the trigger/function side. This confirms the root cause is RLS enabled on auth.users itself (owned by supabase_auth_admin) with zero policies, which I cannot disable due to insufficient ownership permissions (ERROR: 42501: must be owner of table users).

This is still actively blocking all new user signups in production. Could someone with internal access please disable RLS on auth.users for this project (or confirm supabase_auth_admin's BYPASSRLS status hasn't been affected)?

Happy to provide further diagnostics if needed.

Thanks,

[GaryAustin1]

RLS is supposed to be on auth.users and supabase_auth_admin owns those tables so does bypass RLS even with BYPASSRLS off.
RLS IS NOT the issue on auth.users...