Why Joomla 3 Rejects Every Administrator After Root Asset Loss

An administrator enters the correct Joomla username and password, but the backend responds with:

Warning: You do not have access to the Administrator section of this site.

The message confirms that Joomla has rejected the account’s administrative permissions. It does not prove that the password is wrong, that the account has been hacked or that the Root Asset is missing.

One serious cause is the loss of the Root Asset, normally the root.1 row in the #__assets database table. This record sits above Joomla’s component, category and content permissions. If it is absent or damaged, Joomla may be unable to establish what any administrator is allowed to do.

This guide explains how to confirm the fault, rule out simpler account problems, restore the original Root Asset where possible and create limited emergency access when no usable backup remains.

Joomla 3 warning: Official support for Joomla 3 ended on 17 August 2023, and Extended Long-Term Support ended on 17 February 2025. Restoring access does not make an unsupported installation secure. Recovery should be followed by an extension review and a planned move to a supported Joomla release. Joomla technical requirements

Before changing anything

Database repair carries a real risk of making the ACL tree worse. Do not begin with an INSERT, UPDATE, DELETE, repair button or asset rebuild.

Complete these safeguards first:

Take the site offline or restrict access at the web server, hosting panel or firewall.
Create a full database export, even though the database is already damaged.
Copy the website files, including configuration.php and hidden server-control files such as .htaccess.
Record the current date, database name and table prefix.
Work on a clone first whenever the site can be copied to a separate database.
Keep the original export unchanged. Create a second copy for testing.

For a command-line MySQL or MariaDB export, a typical command is:

mysqldump --single-transaction --routines --triggers \
  --default-character-set=utf8mb4 \
  -u DATABASE_USER -p DATABASE_NAME \
  > before-root-asset-repair.sql

This creates a database dump before any repair. Replace DATABASE_USER and DATABASE_NAME with the site’s details. The command requests a transaction-consistent export for InnoDB tables; other storage engines may require a maintenance window or table locking.

If phpMyAdmin is used instead:

Select the Joomla database.
Open Export.
Choose Custom.
Select all tables.
Choose SQL and enable options that add DROP TABLE and CREATE TABLE statements.
Download the export rather than opening it in the browser.
Confirm that the downloaded file is not empty.

How Joomla’s Root Asset works

Joomla stores permissions in #__assets, where #__ represents the table prefix set in configuration.php.

The assets form a hierarchy using a nested-set structure. Each record contains:

id — the database identifier.
parent_id — the parent asset.
lft and rgt — the record’s position and boundaries in the tree.
level — its depth in the tree.
name — a name such as root.1, com_content or com_content.article.42.
rules — the permissions saved as JSON text.

The Root Asset normally has:

id = 1
parent_id = 0
level = 0
name = 'root.1'
a left boundary at the start of the tree
a right boundary greater than every child asset boundary

Joomla reads rules from the requested asset and its parents until it reaches the global Root Asset. A user granted core.admin at the global level is permitted to perform any Joomla action. Joomla permissions documentation

The Joomla 3 API also confirms that an authorisation check without a specified asset falls back to the Root Asset. Joomla 3 Access API

Find the correct table prefix

Open configuration.php in the Joomla root and locate:

public $dbprefix = 'abc_';

In this example, replace every jos_ used below with abc_.

Do not assume that the prefix is jos_. Modern Joomla installations commonly use a generated prefix.

Confirm that authentication succeeds

The access-denied message normally appears after Joomla has accepted the login details but rejected backend authorisation. Check these simple points before touching the asset tree:

Enter the username rather than the email address unless the site explicitly supports email login.
Confirm that the account has not been blocked.
Confirm that it still belongs to the intended administrative group.
Check whether a user-management, authentication or access extension was changed recently.

Run the following read-only query, replacing the prefix and username:

SELECT
    u.id AS user_id,
    u.username,
    u.email,
    u.block,
    m.group_id,
    g.title AS group_title,
    g.parent_id AS group_parent_id
FROM jos_users AS u
LEFT JOIN jos_user_usergroup_map AS m
    ON m.user_id = u.id
LEFT JOIN jos_usergroups AS g
    ON g.id = m.group_id
WHERE u.username = 'YOUR_USERNAME';

Interpret the result carefully:

No row: the username does not exist in this database or the wrong database was selected.
block = 1: the account is blocked.
No group_id: the account has no direct user-group assignment.
Unexpected group: the user mapping may be the real fault.
Expected administrative group: continue with the Root Asset checks.

The default Joomla Super Users group is commonly ID 8, but do not assume that ID 8 is correct on this site. Groups can be changed, imported or recreated.

Check the Root Asset without changing it

Run:

SELECT
    id,
    parent_id,
    lft,
    rgt,
    level,
    name,
    title,
    rules
FROM jos_assets
WHERE id = 1
   OR name = 'root.1';

The result determines the next action.

Result	Meaning	Next action
No rows	The Root Asset is missing	Continue with structural checks
One valid `root.1` row at ID 1	The Root Asset exists	Do not insert another row
ID 1 belongs to another asset	The primary-key structure is damaged	Stop and restore on a clone or obtain specialist help
`root.1` exists under another ID	The hierarchy differs from the expected Joomla structure	Stop before changing IDs
`parent_id` is not 0	The Root Asset has been incorrectly parented	Compare it with a same-site backup
`level` is not 0	The tree depth is wrong	Compare it with a same-site backup
`rules` is empty or unexpected	Global permissions may have been replaced	Restore the original rules rather than inserting a new asset

Never insert a second Root Asset when root.1 already exists.

Check the administrator component asset

The com_admin asset is also involved in backend access. Run:

SELECT
    id,
    parent_id,
    lft,
    rgt,
    level,
    name,
    title,
    rules
FROM jos_assets
WHERE name = 'com_admin';

On a normal Joomla installation, this asset should exist beneath the Root Asset. Its exact ID and boundaries must be read from the affected site or a backup, not copied from another website.

If the Root Asset exists but com_admin is absent, incorrectly parented or contains unexpected rules, the problem is not a missing Root Asset. Do not use the Root Asset INSERT from this guide.

Check whether the remaining asset tree can support a repair

Find the current outer boundary

SELECT
    COUNT(*) AS asset_count,
    MIN(lft) AS smallest_lft,
    MAX(rgt) AS largest_rgt
FROM jos_assets;

The Root Asset’s right boundary must sit outside the remaining children. A fixed value copied from an article cannot account for the assets installed on this site.

Joomla’s own development discussion notes that new asset boundaries cannot be safely assumed because they depend on the affected asset tree. Joomla asset issue discussion

Find records with impossible boundaries

SELECT
    id,
    name,
    parent_id,
    lft,
    rgt,
    level
FROM jos_assets
WHERE lft >= rgt
   OR lft < 0
   OR rgt < 1;

If this returns rows, the tree has damage beyond a missing root. A calculated Root Asset boundary will not repair those records.

Find missing parents

SELECT
    child.id,
    child.name,
    child.parent_id
FROM jos_assets AS child
LEFT JOIN jos_assets AS parent
    ON parent.id = child.parent_id
WHERE child.parent_id <> 0
  AND parent.id IS NULL;

If the Root Asset is missing, direct children with parent_id = 1 will appear here. Rows referring to other missing parent IDs point to wider damage.

Find duplicate asset names

SELECT
    name,
    COUNT(*) AS occurrences
FROM jos_assets
GROUP BY name
HAVING COUNT(*) > 1;

Duplicate names require investigation before a rebuild.

Choose the correct recovery route

Use this order:

Restore the Root Asset from a known-good backup of the same site.
Recover its values from a recent staging copy of the same site.
Reconstruct the site’s global permissions from documented ACL settings.
Create a temporary emergency Root Asset only when no original data remains.

Do not copy a complete Root Asset row from an unrelated Joomla website. Its rgt boundary and rules value belong to that other site.

Preferred method restore the original Root Asset

Step 1 Import the backup into a separate database

Do not overwrite the live database with an untested backup merely to retrieve one row.

Create an empty temporary database.
Import the last known-good same-site SQL backup.
Confirm that its table prefix matches the backup.
Query its Root Asset:

SELECT
    id,
    parent_id,
    lft,
    rgt,
    level,
    name,
    title,
    rules
FROM backup_assets
WHERE id = 1
   OR name = 'root.1';

Replace backup_assets with the table name in the imported backup.

Step 2 Compare the backup with the damaged site

Confirm that:

The backup belongs to the same website.
The Root Asset is root.1 at ID 1.
The global permissions in rules make sense for the site.
The backup is recent enough to reflect the current user-group design.
No existing row in the damaged database uses ID 1 or the name root.1.

The backup’s old rgt value may no longer contain every current child if extensions or content were added after the backup. Calculate the current required boundary:

SELECT COALESCE(MAX(rgt), 0) + 1 AS required_root_rgt
FROM jos_assets;

Use the larger of:

the original Root Asset rgt from the same-site backup; or
required_root_rgt from the damaged database.

This is an initial containment boundary. The full tree must still be checked afterwards.

Step 3 Insert the recovered row inside a transaction

Replace every value in angle brackets with the verified same-site value. Do not execute the template while angle brackets remain.

START TRANSACTION;

INSERT INTO jos_assets
    (id, parent_id, lft, rgt, level, name, title, rules)
VALUES
    (
        1,
        0,
        <VERIFIED_ROOT_LFT>,
        <VERIFIED_OR_CALCULATED_ROOT_RGT>,
        0,
        'root.1',
        'Root Asset',
        '<RULES_COPIED_FROM_THE_SAME_SITE_BACKUP>'
    );

SELECT
    id,
    parent_id,
    lft,
    rgt,
    level,
    name,
    title,
    rules
FROM jos_assets
WHERE id = 1;

COMMIT;

If the INSERT reports a duplicate ID or duplicate name, do not change the ID to force it through. Roll back and inspect the existing record:

ROLLBACK;

Step 4 Test administrator access

Start a private browser window.
Open /administrator.
Sign in with a known Super User account.
Confirm that the administrator menu appears.
Open Global Configuration without saving it yet.

If access remains denied, do not add more permissions at random. Recheck the user mapping, com_admin, the Root Asset rules and any explicit denial inherited through the group tree.

Emergency method when no original Root Asset remains

This method creates temporary administrative authority. It does not recreate the site’s previous Global Configuration permissions.

Only use it when all these conditions are true:

id = 1 is unused.
root.1 does not exist under another ID.
The intended emergency account and its group have been verified.
The remaining records do not contain impossible boundaries.
A fresh database export exists.
The change has been tested on a clone where possible.

Step 1 Identify the intended emergency group

List the user groups:

SELECT
    id,
    parent_id,
    lft,
    rgt,
    title
FROM jos_usergroups
ORDER BY lft;

Then confirm that the emergency account is directly mapped to the intended group:

SELECT
    u.id AS user_id,
    u.username,
    u.block,
    m.group_id,
    g.title AS group_title
FROM jos_users AS u
INNER JOIN jos_user_usergroup_map AS m
    ON m.user_id = u.id
INNER JOIN jos_usergroups AS g
    ON g.id = m.group_id
WHERE u.username = 'YOUR_USERNAME';

Write down the verified group ID. Do not select a group merely because it happens to be ID 8.

Step 2 Confirm that the expected root position is free

SELECT
    id,
    name,
    lft,
    rgt
FROM jos_assets
WHERE id = 1
   OR name = 'root.1'
   OR lft = 0;

For this emergency method, the query should return no rows. If it returns anything, stop and investigate.

Step 3 Create the temporary Root Asset

In the SQL below, change only this line first:

SET @emergency_group_id = 8;

Replace 8 with the group ID verified in the previous step.

Then run the complete transaction:

START TRANSACTION;

SET @emergency_group_id = 8;

SET @root_rgt = (
    SELECT COALESCE(MAX(rgt), 0) + 1
    FROM jos_assets
);

SET @root_rules = CONCAT(
    '{"core.login.admin":{"',
    @emergency_group_id,
    '":1},"core.admin":{"',
    @emergency_group_id,
    '":1}}'
);

INSERT INTO jos_assets
    (id, parent_id, lft, rgt, level, name, title, rules)
VALUES
    (
        1,
        0,
        0,
        @root_rgt,
        0,
        'root.1',
        'Root Asset',
        @root_rules
    );

SELECT
    id,
    parent_id,
    lft,
    rgt,
    level,
    name,
    title,
    rules
FROM jos_assets
WHERE id = 1;

COMMIT;

This calculates a Root Asset right boundary immediately outside the largest current rgt value. It grants only core.login.admin and core.admin to the verified emergency group.

It does not restore permissions such as frontend login, offline login, create, edit, delete or edit state for the site’s other groups. Those rules must be recovered or rebuilt after access is restored.

Step 4 Attempt one clean login

Close existing Joomla administrator sessions.
Open a private browser window.
Sign in using the verified emergency account.
Confirm that the backend menu and Global Configuration are available.

If login fails:

Do not grant core.admin to several groups.
Do not paste the default ACL JSON from another site.
Do not change asset IDs to match an example.
Recheck the account mapping, blocked state, com_admin asset and explicit denials.
Restore the pre-repair database export if the change made the condition worse.

Rebuild and validate the asset tree

Regaining access is only the first checkpoint. The remaining assets may still have broken boundaries, missing parents or incorrect rules.

Use a Joomla 3-compatible diagnostic tool carefully

PWT ACL includes diagnostics for Joomla asset tables. Current PWT ACL releases no longer support Joomla 3, so select a historical release that the vendor explicitly marks as compatible with the site’s exact Joomla and PHP versions. Test it on a clone before installation. PWT ACL release history

Within a compatible PWT ACL release:

Open Components.
Open PWT ACL.
Open its Diagnostics area.
Run the read-only diagnosis first.
Save or capture the reported changes.
Apply fixes on the clone.
Test backend and frontend permissions.
Apply the same controlled repair to production only after the clone passes.

Do not confuse Joomla’s Database Fix function or a database table repair with an ACL asset-tree rebuild. They address different problems.

Repeat the structural checks

After the repair, confirm that no impossible boundaries remain:

SELECT COUNT(*) AS invalid_boundaries
FROM jos_assets
WHERE lft >= rgt
   OR lft < 0
   OR rgt < 1;

Confirm that no asset refers to a missing parent:

SELECT COUNT(*) AS missing_parents
FROM jos_assets AS child
LEFT JOIN jos_assets AS parent
    ON parent.id = child.parent_id
WHERE child.parent_id <> 0
  AND parent.id IS NULL;

Confirm that the Root Asset contains every child boundary:

SELECT
    root.lft AS root_lft,
    root.rgt AS root_rgt,
    MAX(child.rgt) AS largest_child_rgt
FROM jos_assets AS root
LEFT JOIN jos_assets AS child
    ON child.id <> root.id
WHERE root.id = 1
  AND root.name = 'root.1'
GROUP BY root.id, root.lft, root.rgt;

root_rgt must be greater than largest_child_rgt.

Restore the full global permission policy

If the emergency method was used, the Root Asset contains only temporary rules. Leaving it that way may prevent editors, managers, frontend users or offline-access groups from performing their normal actions.

Recover the original permission policy from:

An older same-site database backup
A recent staging copy
Screenshots or documentation of Global Configuration permissions
A previous migration copy
A written user-group and ACL specification

Review every permission in System > Global Configuration > Permissions. Depending on the Joomla 3 administrator template and language, the menu wording may vary.

Check at least:

Site login
Administrator login
Offline access
Super User administration
Access to the administration interface
Create
Delete
Edit
Edit state
Edit own

Do not press Save until the displayed permission result for each group has been checked. Saving an incomplete temporary policy may replace the Root Asset rules again.

Test the permissions from the user’s point of view

Use separate test accounts where possible. Do not test everything with the emergency Super User.

Super User tests

Sign in and out of /administrator.
Open Global Configuration.
View extension management.
Open Users and User Groups.
Edit and save a test article.
Open Modules and Plugins.

Administrator and Manager tests

Confirm backend login.
Confirm that only the expected components appear.
Edit a test item.
Check whether publishing and deletion follow the intended policy.

Editor and frontend tests

Sign in to the frontend.
Create or edit content only where permitted.
Confirm that private or registered content remains restricted.
Test multilingual or category-specific permissions if the site uses them.

Work out why the Root Asset disappeared

A missing row proves that data was lost or changed. It does not identify who or what changed it.

Build a timeline using evidence:

Find the last backup containing root.1.
Find the first backup where it is absent.
List core, extension, migration and hosting work completed between those times.
Review database, server, deployment and security logs for the same period.
Compare user accounts and extensions against the earlier backup.
Record confirmed changes separately from assumptions.

Possible areas include:

Manual database work

Look for SQL imports, cleanup queries, copied tables, partial restores or direct ACL changes. A mistaken DELETE, table replacement or incomplete import can remove the row.

A failed restore or migration

Check whether the database import stopped early, excluded tables, mixed prefixes or combined data from different site copies. Row order in a dump is not itself the problem; missing or mismatched data is.

Extension code

Review extensions that manage ACL, users, migrations, database cleanup or content imports. Check their logs and version history before blaming them.

Core or extension updates

An update close to the incident is a timeline clue, not proof. Check the Joomla update log, PHP error log and database changes. Avoid stating that an update deleted the row unless the logs, code or a repeatable test support that conclusion.

Unauthorised access

Treat unexplained database modification as a possible security incident, especially if it appears alongside unknown users, changed files, new scheduled jobs or unfamiliar administrator activity.

Security checks after unexplained Root Asset loss

Restoring backend access does not remove an attacker or a backdoor.

Check:

All Joomla users and user-group mappings, not only visible Super Users
Authentication, user and system plugins
Recently installed or changed extensions
The complete web root for unexpected PHP files or changed core files
configuration.php for changed database, session, cache, log or temporary paths
Web server and PHP logs
Hosting-panel, WAF and CDN logs
FTP, SFTP, SSH and hosting-panel accounts
Database users and remote database access
Cron jobs and scheduled tasks
API keys and external service credentials stored by the site

If unauthorised access is confirmed or strongly suspected:

Isolate the site.
Preserve logs and a copy of the affected files before cleaning them.
Rotate hosting, database, Joomla, FTP, SSH and service credentials from a clean device.
Replace Joomla core files with files from the correct official release package.
Reinstall trusted extensions from clean packages rather than keeping unknown modified files.
Remove unknown users, keys, jobs and backdoors.
Review other sites and accounts sharing the same server.
Return the site to service only after the cause and access paths have been addressed.

Reduce the chance of the problem returning

Move away from Joomla 3. It is outside official and Extended Long-Term Support.
Keep off-site backups with enough history to pre-date a fault that remained unnoticed.
Test restores, not only backup creation.
Use a staging copy for core, extension, PHP and database changes.
Record ACL changes so Global Configuration permissions can be reconstructed.
Restrict direct database access and use individual administrator accounts.
Monitor file, user and extension changes.
Review logs after failed updates or migrations rather than assuming the site recovered by itself.

Further notes

The safe repair order is:

Back up the damaged state.
Confirm the user and group mapping.
Check both id = 1 and name = 'root.1'.
Inspect com_admin and the remaining tree.
Restore the original same-site Root Asset where possible.
Use temporary emergency rules only when no original data remains.
Validate and rebuild the complete asset hierarchy.
Restore the full global permission policy.
Test with several user roles.
Investigate the cause and complete a security review.
Plan the move to a supported Joomla version.

A missing Root Asset can be repaired, but there is no universal row that can be pasted safely into every Joomla database. The site’s own user groups, permission rules and asset boundaries must decide the repair values.