Skip to main content

The system could not perform “GRANT” statements on the database

Comments

15 comments

  • 24x7server
    Hello :), Are you getting any error while creating backup of this user ?
    0
  • richyb
    Thanks for the reply, Sorry i'm not sure what you mean here. Excuse my ignorance i'm not technically minded when it comes to this.
    0
  • Charlottezweb
    Not to hijack this thread but I encountered the same thing tonight when trying to move an account. Never seen this before. No errors that I'm spotting in the pkgacct output but it fails to restore on the new server. What's worse, when you go into the cPanel account on the new server and go into the MySQL db's page, the mysql users are all there however there are zero db's. If you try to create the db manually there, it says it already exists even though it also says you have zero db's. Guess I'll have to kill the account and manually move...
    0
  • cPanelMichael
    Hello, Could you verify if MySQL is configured on a remote server on this installation, and if so, the version of MySQL installed on the remote server? Thank you.
    0
  • Charlottezweb
    Hello, If that question was for me -- That actually ended up being part of the problem if memory serves. We were not using remote mysql on the source or destination servers however when I ran the restore, it somehow enabled that feature. That was part of the problem. When that was reversed, we were able to get things corrected and change ownership on the db's so they started displaying/functioning properly in the user's cPanel.
    0
  • cPanelMichael
    The closest internal case I can find to that issue is addressed in cPanel version 58: Fixed case CPANEL-3883: RemoteMySQL: Check the version of MySQL as part of the validation process. However, if you are reporting an issue where restoring an account automatically enables a remote MySQL profile, could you open a support ticket using the link in my signature so we can take a closer look? Thank you.
    0
  • MatthewJC
    Hi, I'm experiencing the same issue. Trying to restore a cpmove file, or restore an existing account using 'Backup restoration' "completes" with the warning: Warning: The system failed to reinstall the MySQL database "DATABASENAME" as "DATABASENAME" because of an error: Failed to grant "DBUSER" access to "DATABASENAME": The system could not perform "GRANT" statements on the database "DATABASENAME" for the user "DBUSER" due to an error: (XID 5ugdvn) DBD::mysql::db do failed: Can't find any matching row in the user table. The account restores successfully, apart from the database(s). Server is using a local installation of MySQL. Analyzing the user table in the mysql db returns no issues. WHM version: 56 MySQL version: 5.5.45 Any advise would be appreciated.
    0
  • cPanelMichael
    Hello, Check to see if skip-name-resolve or some variation of that option is enabled in your /etc/my.cnf file. If so, please remove that option, as it's not a default option we test against for MySQL servers. Restart MySQL after removing that option:
    /scripts/restartsrv_mysql
    You should then be able to successfully restore the accounts. Thank you.
    0
  • ribo
    Hello, Check to see if skip-name-resolve or some variation of that option is enabled in your /etc/my.cnf file. If so, please remove that option, as it's not a default option we test against for MySQL servers. Restart MySQL after removing that option:
    /scripts/restartsrv_mysql
    You should then be able to successfully restore the accounts. Thank you.

    Hello i m facing the same issue in whm 58 v32. When i disable skip-name-resolve the error dissapear but when i restart mysql from /scripts/restartsrv_mysql then i have this error 2016-10-14 21:32:56 15722 [Warning] /usr/sbin/mysqld: Forcing close of thread 6 user: 'eximstats' 2016-10-14 21:32:56 15722 [Warning] /usr/sbin/mysqld: Forcing close of thread 1541 user: 'leechprotect' (This error dissapear when i enable skip-name-resolve) I think that to disable skip-name-resolve is not a clear solution. I didnt have this database error before with skip-name-resolve enabled.
    0
  • cPanelMichael
    Hello @ribo, That's normal output when restarting MySQL. It shows that MySQL process was closed. The "skip-name-resolve" MySQL option can cause problems on any server, however it can create more problems on remote MySQL servers, during account transfers and restorations, and with phpMyAdmin. Thank you.
    0
  • ribo
    Is there any way to fix "GRANT" statements error in back up and also to have "skip-name-resolve" MySQL option enabled?
    0
  • cPanelMichael
    Is there any way to fix "GRANT" statements error in back up and also to have "skip-name-resolve" MySQL option enabled?

    Hello @ribo, Our product isn't designed or tested with the skip-name-resolve option enabled in the MySQL configuration file. Could you let us know what in-particular about this option is leading to enable it? Thank you.
    0
  • ribo
    Hello @ribo, Could you let us know what in-particular about this option is leading to enable it? Thank you.

    Hello, i believe that mysql is more optimized and faster with skip-name-resolve enabled
    0
  • cPanelMichael
    Unfortunately, we can't recommend enabling that option. However, feel free to browse our "Workarounds and Optimization" forum if you'd like information about optimizing your MySQL configuration through other changes: Workarounds and Optimization Thank you.
    0
  • benjpw
    In my case, I'd accidentally changed the collation on the mysql.db table/columns. Manually restoring the correct collation allowed the transfer(s) to succeed.
    0

Please sign in to leave a comment.