# Unable to access admin panel

**URL:** <https://community.localwp.com/t/unable-to-access-admin-panel/52148>\
**Category:** Support\
**Tags:** windows, wp-admin\
**Created:** [May 3, 2026, 8:01am UTC](https://community.localwp.com/t/unable-to-access-admin-panel/52148 "2026-05-03T08:01:04Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![leyeah](https://avatars.discourse-cdn.com/v4/letter/l/3d9bf3/32.png) [@leyeah](https://community.localwp.com/u/leyeah)\
**Post date:** [May 3, 2026, 8:01am UTC](https://community.localwp.com/t/unable-to-access-admin-panel/52148/1 "2026-05-03T08:01:04Z")

</div>

**Bug Summary**  
When importing a site via ZIP in Local WP, if the database table prefix in the imported database contains uppercase letters (e.g. `Bwcvqcqk`), Local WP generates the `wp-config.php` with the prefix in lowercase (e.g. `bwcvqcqk`). This mismatch causes WordPress to be unable to read user roles from `wp_usermeta`, resulting in the error “Sorry, you are not allowed to access this page” when trying to access /wp-admin, even though the user exists and the capabilities record is present in the database.

**Steps to reproduce**

1. Export a WordPress site as a ZIP file where the database table prefix contains uppercase letters.
2. Import the ZIP into Local WP using the drag-and-drop or import site feature.
3. Start the site and navigate to [https://yoursite.local/wp-admin](https://yoursite.local/wp-admin).
4. Log in with valid credentials.
5. Observe the error: “Sorry, you are not allowed to access this page.”
6. Check wp\_usermeta (or the prefixed equivalent): the meta\_key for capabilities is stored with the original mixed-case prefix (e.g. `Bwcvqcqkcapabilities`), but WordPress looks for it using the lowercase prefix defined in wp-config.php (e.g. `bwcvqcqkcapabilities`), so the role is never found.

**Environment Info**

- Operating System: Windows
- Web server: nginx (Local WP managed)
- PHP, MySQL: Local WP default versions for the imported site
- Local WP version:Version 10.0.0+6907

**Supporting info**  
The fix is manual: open wp-config.php and ensure `$table_prefix` matches the actual table prefix in the database exactly, including case. Alternatively, update the `meta_key` values in the usermeta table to match the lowercase prefix Local WP writes to wp-config.php.

---

<div class="post-metadata">

**Author:** ![Nick-B](https://sea1.discourse-cdn.com/flex019/user_avatar/community.localwp.com/nick-b/32/16140_2.png) [@Nick-B](https://community.localwp.com/u/Nick-B)\
**Post date:** [May 4, 2026, 12:51pm UTC](https://community.localwp.com/t/unable-to-access-admin-panel/52148/2 "2026-05-04T12:51:13Z")

</div>

Hi @leyeah - Thank you for sharing your replication and resolution steps here for others to find! We do see users run into it from time to time, but it’s more of an OS/platform bug than a Local one.

> It looks like the general issue has to do with the fact that Windows’ file system is case-insensitive, while the remote, UNIX-y file system is case sensitive. Because Windows is case-insensitive, this can cause problems with MySQL when changing environments.

> [@Database tables case issue](https://community.localwp.com/t/database-tables-case-issue/19349/6):
>
> I’ve been taking a closer look at things and I think I have more information to help out with this issue. Thanks for you patience with this, and sorry for the delay – it’s been a tricky thing to zero in on. It looks like the general issue has to do with the fact that Windows’ file system is case-insensitive, while the remote, UNIX-y file system is case sensitive. Because Windows is case-insensitive, this can cause problems with MySQL when changing environments. The MySQL documentation goes int…