There are 3 updates, 1 comment.
 
 
XWiki Docker images / cid:jira-generated-image-avatar-fbe3d620-65a0-4ec8-a975-f134ff433be9 XDOCKER-231 Closed

MariaDB/MySQL permissions not set correctly

 
View issue   ยท   Add comment
 

3 updates

 
cid:jira-generated-image-avatar-322dedee-02ad-43bd-acdb-9dc0b61fe63c Changes by Vincent Massol on 17/Jul/26 17:27
 
Assignee: Vincent Massol
Resolution: Incomplete
Status: Open Closed
 
 

1 comment

 
cid:jira-generated-image-avatar-322dedee-02ad-43bd-acdb-9dc0b61fe63c Vincent Massol on 17/Jul/26 17:27
 

Thanks for the report. First, a general note: JIRA is our issue tracker for confirmed bugs and feature requests, not a support channel. Questions, troubleshooting and "is this a bug?" discussions should be raised on the forum at [https://forum.xwiki.org] instead, where the community can help. Please use the forum for this kind of investigation.

On the substance, this doesn't appear to be a bug in the XWiki Docker image or in XWiki's MySQL/MariaDB support:

  • You mention that the XWiki instance itself works fine (creating pages, installing extensions). That confirms the JDBC connection and the database privileges for the main wiki are correct -- so this isn't a case of XWiki mishandling MySQL/MariaDB privileges.
  • "Empty databases in phpMyAdmin even as root" almost certainly means phpMyAdmin is connected to a different database server (or schema view) than the one used by the container. XWiki stores its data in the xwiki schema plus one additional schema per subwiki; if the application works, the tables do exist.
  • Error 13: Permission Denied is a filesystem error (errno 13 = EACCES), not a database-privilege error. Creating a subwiki also writes a Solr core under the permanent directory (/usr/local/xwiki). When the image is deployed via a GitLab CI/CD runner, the bind-mounted volume can get host ownership that the Tomcat process inside the container cannot write to -- which matches the file-ownership behaviour you observed. This is a deployment/volume-mount concern in your environment rather than something the image controls.
  • For the database side of subwiki creation, the docker-compose setup already ships an init.sql that runs grant all privileges on . to xwiki@'%' (added in XDOCKER-118), and this is documented in the README. That grants the privileges required to create the new schemas that subwikis need.

We test MySQL and MariaDB automatically and manually and they work fine. Since the report is based on a self-contradicting "core bug" claim and no logs/stack trace were provided, I'm closing this as Incomplete. If, after investigating on the forum, a genuine reproducible bug is identified, please open a fresh issue with the full Error 13 stack trace, the XWiki logs, and details of how you mount and set ownership on the volumes under your GitLab runner.