mirror of
https://github.com/BookStackApp/BookStack.git
synced 2026-02-08 03:09:39 +03:00
production.ERROR: BookStack\Users\Models\User::getGuest(): #5313
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @phelgren on GitHub (Jun 16, 2025).
Attempted Debugging
Searched GitHub Issues
Describe the Scenario
I had to do a recovery on a database corruption that damaged the Bookstack database I had running.. I think the database I had was Mariadb 10.1 and I recall having to upgrade to 10.6 in order to update to the latest BookStack running in December. I have recovered the DB in MariaDB 10.1 but the error I am receiving seems to indicate a DB issue (guess). I am not sure of the best way that I have a DB that is compatible with v24.12 which is what I have. Is there a way to confirm the DB integrity and version?
Thanks
Exact BookStack Version
v24.12
Log Content
Hosting Environment
IBM i PASE environment - Roughly AIX 7.2 (not an issue really, BookStack ran great prior to the DB corruption)
@ssddanbrown commented on GitHub (Jun 16, 2025):
Hi @phelgren,
That's odd. As a first step, if you look at the
userstable in the database is there data?system_namecolumn?system_nameispublic?@phelgren commented on GitHub (Jun 16, 2025):
Yes. There are only two records in the table. One is for admin and the
system name is blank in that row, and one for guest and the system name
is 'licgue' in that row
Pete Helgren
www.petesworkshop.com
CISSP - MSCM
GIAC Cloud Penetration Tester
AWS Certified Cloud Practitioner
Microsoft Certified: Azure Fundamentals
@ssddanbrown commented on GitHub (Jun 17, 2025):
Hi @phelgren,
Okay, that's strange. The
licguelooks like it's maybe a malformed combination ofPublicandguest.What kind of recovery process did you end up performing in this environment?
@phelgren commented on GitHub (Jun 17, 2025):
I used an application called Stellar Repair because my DIY attempts didn't bear any fruit. What should the values be? Also, it seems that all of the records have a "deleted at" date...is that normal? Finally, on the pages table the "editor" column has a value of iwyg - that doesn't look right either...
@ssddanbrown commented on GitHub (Jun 17, 2025):
Okay, I'm not convinced you have healthly repaired database content at this stage.
What kind of prior files and/or backups do you have available?
@phelgren commented on GitHub (Jun 17, 2025):
I don't have a backup of any value. I do have a very early DB that I used to test with. I have been comparing the two DB's, table by table. The one I really need is really jacked up. Many slugs are truncated or garbled, I don't know why. But I put too much time into the book to start over at this point. I guess I'll just have to do a side by side until the app starts responding again. I might start with fresh db, add a few chapters and pages to get a sense of what the values really should be and then manually update the tables in the corrupted DB.
Learning a few valuable lessons but I never anticipated a DB corruption like this so I'll just do what I can.
And, if I DO want to start with an empty DB, do I just rename the existing DB and then use php artisan migrate to initialize the DB in the existing BookStack app?
@ssddanbrown commented on GitHub (Jun 18, 2025):
Do you still have the files from before any attempted fixes (Especially via Stellar Repair)?
I've been able to help a handful of folks in the past who have ended up in corrupted states.
@phelgren commented on GitHub (Jun 18, 2025):
Thanks for the offer...here is what I think happened but I am not sure. I wanted to upgrade Bookstack but noticed that it required 10.2 of MariaDB or higher. So I "upgraded" to 10.6, upgrade is in quotes because I think I installed a separate instance of MariaDB rather than upgrade what was there. I am not sure what I ended up with. The DB folder containing the 10.1 version seemed to have all the records of the new pages I added after the BookStack upgrade, which made no sense since the new install "seemed" to be pointed to a different folder. But I discovered this after the system had been shut down and shipped to a new location. When the system came up, I had issues starting two WordPress instances and the Bookstack instance so I assumed there was an error in starting the Mariadb instances. I was finally able to at least start the Mariadb instances but still no joy in starting the apps using the DB's. So I opened up the DB instances with an SQL client and all seemed well until I started perusing the tables. I got a series of "Table xxx doesn't exist..." errors even through you could see the table entries in the DB. It was hit or miss as well. Not all the DB's were corrupted. Some were just fine. Attempting to repair the DB's with DIY methods found on the web didn't help. I didn't perform those repairs on the original folders, only copies of them.
As I think it through, after the install of 10.6 and starting that Mariadb instance I am beginning to wonder if somehow the folders the Mariadb instances got "crossed": some pointing to the old location and some to the new, so some the db folders were mixed (don't even know if this is possible) I do know that after I discovered that things were a mess, I took snapshots of the DB folders. I have been making copies of those folders as I have attempted to repair them, rather than working directly on the backed-up folders. I do recall seeing an error message when I attempted to open the DB's initially something like "created at 10121 but opened at 10621" (or something like that).
I would just like to get everything to the 10.6 level. Bookstack is one of the critical DB's and I have another, much more complex one that I would like to recover as well. Stellar has not been, well. stellar in getting the corruption fixed....
@ssddanbrown commented on GitHub (Jun 18, 2025):
Yeah, In the rare few times I've had corruption reported, accidentally running multiple databases against the same data has been a cause, which of course docker makes easier than normal.
I've had success before opening up the files with a mariadb container, that's specifically matched to the content version, although not starting the default mariadb process, but instead manually running safe-mode/recovery commands (can't remember exactly) to recover via the old version, then (once a safe sqldump had been made), safely walk the data up some versions.
@ssddanbrown commented on GitHub (Aug 29, 2025):
Since there's been no further follow-up I'm going to close this off.
Just ask if further support is needed though.