Sorry, a mysql user with the name x already exists.

PCZero

Well-Known Member
Dec 13, 2003
718
85
178
Earth
NONE OF THIS FIXED THE ERROR FOR ME. I RAN THE COMMAND grep -Rl USERNAME /var/cpanel/databases/ AND SAW TWO LISTINGS FOR THE USER. I THEN RAN /usr/local/cpanel/bin/setupdbmap. RERUNNING THE FIRST COMMAND RETURNED NO FILES AFTER THE SECOND WAS RUN. I TRIED TO ADD THE ACCOUNT AGAIN AND STILL GET THE MYSQL USER ERROR MESSAGE. WTF?
 

Vinil

Registered
Jan 16, 2012
2
0
51
cPanel Access Level
Website Owner
drop that database either or try installing database in some other system and check whether it gives same issue or not ?
 

CyberFunk

Registered
Jun 26, 2011
4
0
51
omg=)

grep -Rl USERNAME /var/cpanel/databases/ | xargs -i sed -i '/USERNAME/d' {}

should be easy to run this for dummies even
 

ServIntNOC

Registered
PartnerNOC
Oct 19, 2002
3
0
151
Since I submitted a cPanel ticket for this issue, and it was simple to resolve, I feel it should be easily accessible to the public.

I was receive this error when creating a cPanel account which was terminated with the WHM tool. I checked /var/cpanel/databases/ files as suggested and removed any trace. I then went into mysql and looked for the user in the users table. Not there.

After submitting the ticket, the cPanel tech was able to fix it:

"The user existed in /etc/passwd so the account wasn't fully removed. I have removed the account and also removed it from /etc/dbowners. I was then able to create an account fine
with this user."

It seems I missed a few files in my user search. Maybe a grep of the /etc folder would have turned this up, but could have taken a while.

Anyways, shout out to Eric D at cPanel support! He fixed it for me.
 

acenetryan

Well-Known Member
PartnerNOC
Aug 21, 2005
197
1
168
A word of warning to anyone encountering the error "Sorry, a mysql user with the name x already exists." The suggestions on this thread to manually remove the entries from

/var/cpanel/databases/users.db.cache
/var/cpanel/databases/users.db

ended up creating more problems for me. When attempting to create an account after manually removing the user's entries from these files resulted in the creation process sitting at "Checking input data". I posted a ticket and cPanel staff advised me:

James Otting said:
The files there in /var/cpanel/databases are very particular about formatting, and usually cannot be edited by hand. That said, they're actually very easy to rebuild as long as you've not disabled database prefixing. As you have not, I simply removed all the files from /var/cpanel/databases/ and then ran /usr/local/cpanel/bin/setupdbmap to regenerate all the database mapping there from the actual users/dbs in mysql. Other files (like the caches) will be rebuilt automatically as needed. I was then able to create a test account (cptest) without issue. Please try things out yourself, and if you have further problems or questions, just let me know.
Based on James' response, I'm guessing that rebuilding these files is more tricky if you're not using database prefixing. My suggestion if you encounter the "Sorry, a mysql user with the name x already exists." error is to simply post a ticket with cPanel and have them take a look. Better safe than sorry.
 
Last edited:

cPanelTristan

Quality Assurance Analyst
Staff member
Oct 2, 2010
7,607
40
248
somewhere over the rainbow
cPanel Access Level
Root Administrator
We've been told specifically by development not to run /usr/local/cpanel/bin/setupdbmap on servers already converted to not have database prefixing. Here's a quote by one of the developers recently:

setupdbmap should not be run on a system that has disabled database prefixing. Additionally, running on a system that has been hacked back ( disable->enable prefixing) could/will have undesirable consequences/mappinng.

Anytime you suspect that executing setupdbmap is the proper course of action, I'd audit the results of the cpuser accounts to make sure no ancillary changes occurred outside the account you're trying to fix.
Basically, I would not suggest ever using that script unless the ramifications are truly understood. It is not the way to fix this type of issue on systems with database prefixing disabled. I realize it was specifically mentioned about the system not having database prefixing disabled, but my concern here is now the script has been mentioned and someone will run it when it shouldn't be run simply because it's been mentioned on here. Some people don't check or know if they do or don't have prefixing disabled. The script just plain shouldn't be mentioned in any situation due to the likelihood you might cause more problems than solve them.
 

JaredR.

Well-Known Member
Feb 25, 2010
1,834
24
143
Houston, TX
cPanel Access Level
Root Administrator
He require my password root?, he need loguin in my server? NO!
We do not need to see your root password. We have implemented a log-in system that works in conjunction with our ticket system and allows us to log into your server without a technical analyst ever seeing your root password. This is a significant change from the past and it was done to increase the security of our customers' interactions with support.

Rest assured that, if you submit a ticket, technical analysts will not see your server's root password, and in fact, if you happen to put a root password in a ticket reply, it will actually be removed, so it will not be stored in a format that any of us could ever read in the future.

You also have the option of generating a public/private key pair and giving us the public key, again through the ticket system so we do not see it directly, so you never actually give us the root password. You can then deauthorize or remove the public key from your server when the support request is completed. That way we literally have no possible way to log into the server once the ticket is completed.

It is extremely difficult to think of all the possible circumstances and custom modifications that can exist on our customers' servers, since they are used for such a wide variety of purposes, so sometimes it is impossible to provide an exact solution without seeing the server directly, and that is why on this forum we sometimes recommend submitting a ticket. Your server's log-in information is handled very delicately, the password is not seen by technical analysts, and we do not log in unless there is no other way to troubleshoot a problem.

We can usually provide a solution more quickly via a ticket, if you allow us to access the server, because we can look at the problem directly instead of asking you a question, waiting for a reply, asking another question, making a suggestion, and so on. We recommend that if there is a critical problem that is affecting your business, or a service is down, that you submit a ticket, because it is usually more efficient than the forum. Again, we never log in unless it is required, your log-in information is handled very securely, and technical analysts never actually see the log-in information directly.
 

ahmedraafat

Registered
Nov 13, 2013
1
0
1
cPanel Access Level
Root Administrator
Hi,

I faced same problem and spent a lot of time till found the final solution

1- use Putty or WinSCp to connect to your root server

2- move to : root > var > cpanel > databases

3- search for file called ( users.db )

4- Open it in editor , search for user name of account and delete it

5- upload users.db after editing and overwrite the old one

now go ahead the process will done perfect and you can add the account without any extra problems

:)
 

djalpha

Active Member
Jan 20, 2003
30
0
156
one more easy way

dont touch to anything

open to phpmyadmin with root
find database mysql
find under mysql user table and delete all isued username
restart mysql (service mysql restart)
 

njak

Member
Feb 7, 2004
11
0
151
Columbus, OH
I just had this problem - I deleted an account and was restoring it from another server. Since the entire site had been deleted, the database user should have been gone. I checked using phpMyAdmin, and it was gone.

I restarted mySQL and it restored the account from backup. It must process it all the way after some time, or upon reboot of mySQL.