PostgreSQL authentication failure during container bootstrap on Azure VM (role created without password)

Question

Hello Azure Support Team,

I am running a self-hosted PostgreSQL-based stack on an Azure VM using Docker Compose, and I am blocked by a database authentication issue that appears during initial database bootstrap. I suspect this may be related to filesystem behavior, volume mounts, or permissions on the Azure VM.

Summary of the issue

A PostgreSQL role required by the application (supabase_auth_admin) is created during initial database initialization without a password. This causes all dependent services to fail authentication and continuously restart.

The role is marked as reserved and cannot be modified after creation, so the only way to fix this is a clean and successful database bootstrap — which is not occurring even after a full reset.

Observable symptoms

• PostgreSQL container starts and reports healthy

Multiple dependent containers repeatedly restart due to auth failures

PostgreSQL logs and client logs show:

password authentication failed for user "supabase_auth_admin"

Direct inspection of PostgreSQL system catalog shows:

   SELECT rolname, rolpassword IS NOT NULL AS has_password
FROM pg_authid
WHERE rolname = 'supabase_auth_admin';

Result:

   supabase_auth_admin | false

What I have already done

Fully stopped and removed all containers and volumes:

docker compose down -v

Manually deleted the PostgreSQL data directory on the VM:

  `sudo rm -rf volumes/db/data`
  
  Verified no containers were running before restart
  
  Restarted the database container alone to force clean initialization
  
  Confirmed PostgreSQL initializes cleanly but still creates the role without a password
  
  Verified the role exists and is marked as reserved and unmodifiable
  
  Repeated the entire process multiple times with the same result
  

Why I suspect an Azure environment issue

The database initializes, but some initialization steps appear to be skipped

This behavior typically occurs if:

A volume mount is partially reused

  Filesystem permissions prevent init scripts from executing
  
     The data directory is not truly empty despite deletion
     
     I previously encountered permission inconsistencies on mounted directories (root-owned paths, directories where files were expected)
     

What I am requesting help with

Verification that the VM disk and filesystem allow full deletion and recreation of PostgreSQL data directories

Confirmation that Docker volume mounts and permissions on this VM do not interfere with container initialization

Guidance on whether any Azure VM, disk, or filesystem settings could cause partial persistence of PostgreSQL system catalogs across restarts

I can provide additional logs, configuration files (with secrets redacted), or VM details if needed.

Thank you for your assistance — this issue is currently blocking deployment.

Kind regards, [Your Name]Hello Azure Support Team,

I am running a self-hosted PostgreSQL-based stack on an Azure VM using Docker Compose, and I am blocked by a database authentication issue that appears during initial database bootstrap. I suspect this may be related to filesystem behavior, volume mounts, or permissions on the Azure VM.

Summary of the issue

A PostgreSQL role required by the application (supabase_auth_admin) is created during initial database initialization without a password. This causes all dependent services to fail authentication and continuously restart.

The role is marked as reserved and cannot be modified after creation, so the only way to fix this is a clean and successful database bootstrap — which is not occurring even after a full reset.

Observable symptoms

PostgreSQL container starts and reports healthy

Multiple dependent containers repeatedly restart due to auth failures

PostgreSQL logs and client logs show:

password authentication failed for user "supabase_auth_admin"

Direct inspection of PostgreSQL system catalog shows:

   SELECT rolname, rolpassword IS NOT NULL AS has_password
FROM pg_authid
WHERE rolname = 'supabase_auth_admin';

Result:

   supabase_auth_admin | false

What I have already done

Fully stopped and removed all containers and volumes:

docker compose down -v

Manually deleted the PostgreSQL data directory on the VM:

  `sudo rm -rf volumes/db/data`
  
  Verified no containers were running before restart
  
  Restarted the database container alone to force clean initialization
  
  Confirmed PostgreSQL initializes cleanly but still creates the role without a password
  
  Verified the role exists and is marked as reserved and unmodifiable
  
  Repeated the entire process multiple times with the same result
  

Why I suspect an Azure environment issue

The database initializes, but some initialization steps appear to be skipped

This behavior typically occurs if:

A volume mount is partially reused

  Filesystem permissions prevent init scripts from executing
  
     The data directory is not truly empty despite deletion
     
     I previously encountered permission inconsistencies on mounted directories (root-owned paths, directories where files were expected)
     

What I am requesting help with

Verification that the VM disk and filesystem allow full deletion and recreation of PostgreSQL data directories

Confirmation that Docker volume mounts and permissions on this VM do not interfere with container initialization

Guidance on whether any Azure VM, disk, or filesystem settings could cause partial persistence of PostgreSQL system catalogs across restarts

I can provide additional logs, configuration files (with secrets redacted), or VM details if needed.

Thank you for your assistance — this issue is currently blocking deployment.

Kind regards,
Sadeer

Answer 1

Hi @DevCru

Thank you for contacting Microsoft Q&A. Please find below the detailed steps to address the reported issue.

STEP 1 — Verify and Clean the Azure VM Filesystem

Running docker compose down -v removes Docker volumes, but NOT:

• root‑owned directories,
• bind‑mounted paths,
• orphaned overlay2 layers,
• or partially deleted directories.

# Stop Docker completely

sudo systemctl stop docker

 

# Ensure no containers or mounts remain

docker ps -a

mount | grep docker

 

# Remove leftover directories (critical)

sudo rm -rf /var/lib/docker/volumes

sudo rm -rf /var/lib/docker/overlay2

sudo rm -rf <path-to-your-project>/volumes/db/data

 

STEP 2 — Recreate the Docker engine storage

Some Azure Linux VM images suffer from root‑owned mount points inside ephemeral disks. Reinitialize Docker:

sudo systemctl start docker

sudo docker system prune -a --volumes

 

STEP 3 — Verify the Directory Permissions of Your Mounted Path

sudo mkdir -p volumes/db/data

sudo chown -R $USER:$USER volumes/

sudo chmod -R 755 volumes/

 

STEP 4 — Ensure Init Scripts EXIST and RUN

docker-entrypoint-initdb.d/*.sql

Double‑check:

ls -l docker-entrypoint-initdb.d

If missing/misordered, refer to Supabase bug #36073 which confirms that when init scripts are not executed, roles + tables remain incomplete.

STEP 5 — Perform a True Clean Bootstrap

docker compose down -v

sudo rm -rf volumes/db/data

docker compose up -d db

 

Wait until PostgreSQL is fully initialized (look for: database system is ready to accept connections).

Then verify the role:

docker exec -it <postgres-container> psql -U postgres -c \

"SELECT rolname, rolpassword IS NOT NULL AS has_password FROM pg_authid WHERE rolname='supabase_auth_admin';"

Expected:

supabase_auth_admin | true

If TRUE → your environment is finally clean and correct.

STEP 6 — Bring Up the Entire Stack

docker compose up -d

Note: - Your init scripts never executed due to filesystem/permission inconsistencies — confirmed by the authoritative Microsoft incident report () and reproduced in other Supabase Docker issues ().

Once the environment is genuinely wiped and permissions corrected, PostgreSQL WILL run all initialization scripts and create supabase_auth_admin with the correct password.

KB articles - General PostgreSQL password‑auth failure troubleshooting on Azure

Password authentication failed for user | Microsoft Learn

Answer 2

It seems you are encountering a common issue with PostgreSQL where a role is created without a password, leading to authentication failures. Here are some steps and considerations to help you troubleshoot this problem:

1. Role Creation Without Password: Ensure that the role supabase_auth_admin is not being created without a password during the initialization scripts. If the role is created without specifying a password, it will lead to the authentication failure you are experiencing. You can set the password for the role after creation using the following SQL command:

      ALTER ROLE supabase_auth_admin LOGIN;
      ALTER ROLE supabase_auth_admin PASSWORD '<new-password>';
   

   However, since you mentioned that the role is marked as reserved and unmodifiable, this may not be applicable.
2. Volume Mounts and Permissions: Since you suspect that filesystem behavior or volume mounts might be causing the issue, ensure that the PostgreSQL data directory is completely empty before the initialization. If there are remnants of previous data, it might lead to unexpected behavior during the bootstrap process. You can check the permissions of the mounted directories to ensure that the PostgreSQL process has the necessary access rights to execute initialization scripts.
3. Docker Initialization: When using Docker, ensure that the initialization scripts are correctly placed in the expected directory and that they have the right permissions to execute. If the initialization scripts are skipped, it could be due to permission issues or the presence of existing data in the volume.
4. Azure VM Settings: Verify that the Azure VM disk and filesystem settings allow for full deletion and recreation of PostgreSQL data directories. Sometimes, Azure-specific configurations can lead to unexpected persistence of data across container restarts.
5. Logs and Diagnostics: Review the PostgreSQL logs for any warnings or errors during the initialization phase. This might provide insights into why the role is being created without a password. Additionally, check the logs for any permission-related errors that could indicate issues with the volume mounts.

If you continue to face issues, consider reaching out to Azure support with detailed logs and configurations for further assistance.