WHM Restore Error: Username Conflicts With Unmanaged PostgreSQL User

Fix WHM Restore Error: Username Conflicts With Unmanaged PostgreSQL User

Overview

While restoring a cPanel account in WHM, you may encounter an error stating that WHM cannot create the user because it conflicts with an unmanaged PostgreSQL database user.

This happens when PostgreSQL already contains a role/user with the same name as the cPanel username you are trying to restore.

This article explains the cause and provides the root-level steps to resolve it.

Error Message

You may see an error similar to the following:

 Failed to create the account: (XID XXXXX) The system could not create the user “ucasa” because it conflicts with an unmanaged PostgreSQL database user. at /usr/local/cpanel/Whostmgr/Accounts/Create.pm line 1391. Failed: Account Restore Failed: “Account failure: Failed to create the account: (XID XXXXX) The system could not create the user “ucasa” because it conflicts with an unmanaged PostgreSQL database user. at /usr/local/cpanel/Whostmgr/Accounts/Create.pm line 1391. ” 

Cause

cPanel/WHM requires the account username to be unique.

If a PostgreSQL role/user already exists on the server with the same username (example: ucasa) and it was created outside of cPanel (or remains from a previous configuration), cPanel detects it as an unmanaged PostgreSQL role and blocks the restore to avoid conflicts.

Even if the PostgreSQL role does not own any databases, it may still have privileges on one or more databases, which can prevent the role from being dropped immediately.

Requirements

Root SSH access to the destination server

PostgreSQL installed and accessible via psql

Resolution (Root Access Required)

Step 1: Login to PostgreSQL

SSH into the server as root and open PostgreSQL:

 psql 

Step 2: Confirm if the role exists

Check if the conflicting role exists:

 SELECT rolname FROM pg_roles WHERE rolname='ucasa'; 

You can also list all roles:

 \du 

Step 3 (Optional): Check if the role owns any databases

This helps confirm whether the role is a database owner:

 SELECT datname FROM pg_database WHERE datdba = ( SELECT oid FROM pg_roles WHERE rolname='ucasa' ); 

If it shows (0 rows), the role does not own any PostgreSQL databases.

Step 4: Try to drop the role directly

Attempt to remove the role:

 DROP ROLE ucasa; 

If it succeeds, retry the restore in WHM.

If DROP ROLE Fails

You may receive an error like:

 ERROR: role "ucasa" cannot be dropped because some objects depend on it DETAIL: privileges for database fspzxuga_sayimdb 

This means the role has privileges granted on a database and must be removed first.

Step 5: Revoke database privileges and retry

Run the following to revoke privileges:

 REVOKE ALL PRIVILEGES ON DATABASE fspzxuga_sayimdb FROM ucasa; 

Then retry dropping the role:

 DROP ROLE ucasa; 

If the Role Still Cannot Be Dropped (Advanced Cleanup)

If the role still has permissions inside the database (schemas/tables/default privileges), perform the following additional cleanup.

Step 6: Connect to the affected database

 \c fspzxuga_sayimdb 

Step 7: Remove owned privileges/objects

 REASSIGN OWNED BY ucasa TO postgres; DROP OWNED BY ucasa; 

Step 8: Return to postgres database and drop the role

 \c postgres DROP ROLE ucasa; 

Final Step

Once the role is successfully removed, retry the restore in WHM. The account restore should complete successfully.

Notes / Best Practices

Always confirm the PostgreSQL role is not required by an active application before removing it.

If you prefer not to modify PostgreSQL roles, an alternative is restoring the cPanel account using a different username (example: ucasa1). This may require additional adjustments after the restore.