iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
In MySQL 8.4, creating a login and giving it access are separate operations. Connect with an account that can create users, run CREATE USER with the exact user-and-host pair that will connect, grant only the required privileges, and then verify with SHOW GRANTS and SHOW CREATE USER. If you see Access denied, first identify the host-qualified account MySQL actually used; a grant for 'appuser'@'localhost' does not apply to 'appuser'@'127.0.0.1' or 'appuser'@'%'.
What a MySQL account really is
MySQL identifies an account by two values: a user name and a host. The account 'appuser'@'localhost' is different from 'appuser'@'127.0.0.1' and from 'appuser'@'%'. Each can have a different password, authentication method, and privilege set.
This distinction explains many apparently contradictory errors. You may have granted access correctly, but to a different host-qualified account than the client is using. Always copy the user and host shown in the complete error message before changing grants.
Authentication and authorization are separate
- Authentication determines whether MySQL accepts the account’s credentials and authentication settings.
- Authorization determines what that authenticated account may do after login.
CREATE USER establishes an account but gives it no object privileges. GRANT is the separate step that permits operations such as reading or writing tables.
#1 Best Overall
Prerequisites and safe preparation
- Use an administrative account that has the global
CREATE USERprivilege (or the documented system-schema alternative) to create accounts. - To grant privileges, the granting account needs both the privileges being granted and
GRANT OPTION, subject to MySQL’s documented system-schema rules. - Know the database, tables, connection method, and source host the application will use.
- Decide whether the account needs a password, a particular authentication plugin, TLS requirements, resource limits, or a role. Do not copy a production password into a shared shell history.
Account statements can be recorded in server logs and in client history files such as ~/.mysql_history. Treat passwords in SQL statements as secrets: use a protected administrative session, restrict file permissions, and remove exposed credentials by changing them with ALTER USER.
Do not edit the mysql system tables directly. Use the supported statements CREATE USER, ALTER USER, GRANT, and REVOKE; changing system-table structure can cause unpredictable login failures.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Step 1: Connect as an account allowed to create users
Open a MySQL client using an administrative identity. The exact client command depends on your operating system and connection method; the important requirement is that the session is authorized for account administration.
mysql -u admin -pFor a remote server, specify the server address and, when required, the port:
mysql -h db.example.internal -P 3306 -u admin -pDo not assume that a user called admin has the necessary rights. Confirm the connected account and its grants:
SELECT USER(), CURRENT_USER();
SHOW GRANTS FOR CURRENT_USER;USER() shows the identity supplied by the client, while CURRENT_USER() shows the MySQL account that authenticated the session. The distinction is useful when host matching or authentication rules select a different account than expected.
Free tools Windows power users keep installed
One-click scans. No signup required.
Rank #2
Step 2: Create the exact host-qualified account
Use CREATE USER with a quoted user name and host. This example creates an account for local connections:
CREATE USER 'appuser'@'localhost' IDENTIFIED BY 'strong-secret';The account now exists, but it has no privileges on databases or tables. If an account with the same user-and-host pair already exists, MySQL returns an error rather than silently replacing it. Inspect the account first, or use an intentional account-management change such as ALTER USER when you need to update credentials.
Choose the host value deliberately
| Account host | Typical meaning | Security and operational consideration |
|---|---|---|
localhost |
Connections identified as local to the server, often from a local client or socket configuration. | Restricts the account to local use, but does not automatically match a TCP connection that MySQL identifies as 127.0.0.1. |
A specific address, such as 192.0.2.25 |
Connections from one known client address. | Narrower than a pattern, but it must be updated if the client address changes. |
% |
A wildcard host pattern that can match connections from many addresses. | Convenient for distributed clients but broad; combine it with strong authentication, network controls, and the smallest possible privileges. |
Use the narrowest host expression that supports the real deployment. Creating several accounts with the same user name but different hosts is valid, but each account needs its own password and grants.
Confirm that the account exists
SHOW CREATE USER 'appuser'@'localhost';This statement displays authentication and account attributes. It errors if the named account does not exist, which makes it a direct existence check. Protect its output because authentication details and account settings are administrative information.
Step 3: Grant only the permissions the workload needs
Grant privileges after account creation. A common application grant is:
GRANT SELECT, INSERT, UPDATE
ON appdb.*
TO 'appuser'@'localhost';This allows the account to read, insert, and update objects in the appdb database. It does not grant delete, schema-changing, administrative, or global privileges.
Choose the smallest useful scope
| Grant target | Example | When to use it |
|---|---|---|
| Global | *.* |
Only when the account genuinely needs the privilege across every database; this is the highest-risk scope. |
| Database | appdb.* |
When the application must access many current and future objects in one database. |
| Table | appdb.orders |
When access should be limited to named tables. Prefer this over a database-wide grant when practical. |
| Column | SELECT (order_id, status) ON appdb.orders |
When only particular columns should be visible or writable. |
For a single table, narrow the target:
GRANT SELECT, INSERT, UPDATE
ON appdb.orders
TO 'appuser'@'localhost';Avoid using ALL PRIVILEGES merely to make an error disappear. Broad grants can expose unrelated data and permit destructive or administrative actions. If a migration job needs schema changes, give that job a separate, tightly controlled account instead of expanding the application’s normal login.
Grant a role when privileges are managed centrally
MySQL roles can group privileges for multiple accounts. SHOW GRANTS displays role assignments, but an assigned role may not be active in the current session. Activation depends on the account’s role settings and session state. If a role appears in the grants but its privileges are ineffective, check the active-role configuration rather than immediately adding direct privileges.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Step 4: Verify effective grants before testing the application
Check the exact account you created:
SHOW GRANTS FOR 'appuser'@'localhost';When logged in as the application account, check the session’s effective grants:
SHOW GRANTS FOR CURRENT_USER;In MySQL 8.4, global output explicitly lists the granted privileges instead of depending on a single ALL PRIVILEGES label. Read the object scope, account host, direct privileges, and role assignments in the result. This is the authoritative place to confirm what MySQL has recorded for that account.
Then verify the account definition:
SHOW CREATE USER 'appuser'@'localhost';Finally, connect using the same host, port, and transport that the application uses. A successful test from a local socket does not prove that a TCP connection from another machine will match the same account.
Why “Access denied for user” happens
Oracle’s MySQL 8.4 documentation notes: “An Access denied error can have many causes. Often the problem is related to the MySQL accounts that the server permits client programs to use when connecting.” The failure can occur during account authentication, or after login when MySQL checks whether the authenticated account may perform the requested operation.
Recommended Free Tools
The username or host does not match
An error such as Access denied for user 'appuser'@'127.0.0.1' identifies the host MySQL saw. A grant for 'appuser'@'localhost' will not fix that error. From an administrative session, inspect the exact pair:
SHOW GRANTS FOR 'appuser'@'127.0.0.1';If that account is intended, create it and grant the required scope, or change the client so it connects in the way the existing account expects. Do not solve a host mismatch by granting broad access to an unrelated account.
The password or authentication attributes are wrong
The account may exist with a different password, authentication plugin, expiration state, or other account attribute. Compare the account definition with:
SHOW CREATE USER 'appuser'@'localhost';If the credential must be replaced, use an account statement rather than editing system tables:
ALTER USER 'appuser'@'localhost' IDENTIFIED BY 'new-strong-secret';Because passwords can enter logs or history, change any credential that was exposed in a shared command line or file.
The account can log in but lacks the requested privilege
Some errors occur after authentication when the account tries to select, insert, update, delete, create, or alter an object. Check the current identity and grants from the failing session:
Best Value
SELECT USER(), CURRENT_USER();
SHOW GRANTS FOR CURRENT_USER;Compare the requested object with the grant target exactly. appdb.* covers objects in that database, while appdb.orders covers only one table. A grant on appdb.orders does not cover appdb.customers, and a grant on one database does not cover another with a similar name.
The role is granted but inactive
If SHOW GRANTS shows a role assignment but the operation remains denied, determine whether the role is active in the current session and whether the account’s default-role settings include it. Role assignment and role activation are related but distinct operations.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallThe database or table name is not what you think
Check spelling, letter case where the server’s filesystem and configuration make it significant, and the database selected by the client. Qualify objects in diagnostic statements and confirm the application is connecting to the intended server instance.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.A repeatable permission-error diagnosis
- Capture the full error. Record the user, host, database, object, and operation. Do not truncate the host portion.
- Compare identities. In a session that can connect, run
SELECT USER(), CURRENT_USER();. If the failing account cannot connect, have an administrator inspect the user-and-host pair printed in the error. - Inspect effective grants. Run
SHOW GRANTS FOR CURRENT_USER;from the affected session, orSHOW GRANTS FOR 'user'@'host';as an administrator. - Check account attributes. Run
SHOW CREATE USER 'user'@'host';to verify existence, authentication settings, and account state. - Match scope to the operation. Confirm that the grant covers the exact database, table, and columns involved, and that the privilege type is sufficient.
- Check role activation. A displayed role may not be active for the current session.
- Correct the narrowest problem. Create or alter the correct host-qualified account, grant only the missing privilege, or fix the client connection target.
- Retest with the same connection path. Use the same host, port, protocol, and credentials as the application.
- Remove accidental excess. Revoke temporary or overly broad privileges after the test succeeds.
Correcting common mistakes safely
Granting the wrong host account
Suppose you created 'appuser'@'localhost' but the error names 'appuser'@'192.0.2.25'. Either create the intended specific-host account and grant it the required permissions, or change the application to connect from a host that matches the existing account. The right choice depends on your network design; avoid replacing a narrow host with % just for convenience.
Granting a database when one table was enough
If an application only needs orders, replace an unnecessarily broad database grant with a table grant. First add the correct narrow grant, test the application, then revoke the broader one:
GRANT SELECT, INSERT, UPDATE
ON appdb.orders
TO 'appuser'@'localhost';
REVOKE SELECT, INSERT, UPDATE
ON appdb.*
FROM 'appuser'@'localhost';Review dependent queries before revoking; a background task may use another table that was hidden from the original test.
Assuming CREATE USER also grants access
It does not. If login succeeds but every table operation is denied, the account likely exists without object privileges. Add the least-privilege GRANT, then verify it with SHOW GRANTS.
Editing mysql tables directly
Do not update rows in the mysql system schema as a shortcut. Supported account statements maintain the structures and metadata MySQL expects; direct edits can produce unpredictable login failures.
Security checklist for production accounts
- Use a distinct account for each application, environment, or operational job so privileges can be audited and revoked independently.
- Restrict the host to a known address or network pattern whenever the deployment permits it.
- Grant only the operations and objects required by the workload.
- Keep schema-migration or administrative credentials separate from routine application credentials.
- Protect SQL logs, shell history, automation output, and backups that might contain passwords.
- Use
SHOW GRANTSandSHOW CREATE USERas part of account reviews. - Revoke temporary troubleshooting grants when diagnosis is complete.
- Never expose credentials in source code, issue tickets, or shared chat.
Quick reference: the complete workflow
-- Connect as an authorized administrator
-- Create an account for the actual client host
CREATE USER 'appuser'@'localhost' IDENTIFIED BY 'strong-secret';
-- Grant only the required operations and scope
GRANT SELECT, INSERT, UPDATE
ON appdb.*
TO 'appuser'@'localhost';
-- Verify the recorded grants and account definition
SHOW GRANTS FOR 'appuser'@'localhost';
SHOW CREATE USER 'appuser'@'localhost';
-- When diagnosing from the affected login
SELECT USER(), CURRENT_USER();
SHOW GRANTS FOR CURRENT_USER;If the final test still fails, return to the exact host in the error, compare it with CURRENT_USER(), and inspect that account’s grants. Most permission incidents become straightforward once identity, host, scope, and role activation are checked separately.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
