Skip to main content

Database User Privileges Required for Jahia Installation and Upgrade

Question

Jahia manages its own database schema automatically—both at first installation and during every version upgrade. This means the database user configured in the JDBC connection must have DDL rights (create/alter/drop), not just DML rights (select/insert/update/delete). This article explains what to grant, why, and how to scope it safely.

Why Jahia needs more than read/write access

Jahia’s persistence layer (Apache Jackrabbit for the JCR content repository, plus Hibernate-backed tables for some subsystems) creates and evolves its own tables, indexes, and sequences:

  • On first install: the full schema is created from scratch.
  • On every upgrade: Jahia runs schema migrations automatically at startup on the new version (comparable to a Liquibase-style migration) — adding/altering columns, indexes, or tables as needed for the new release.

If the DB user only has DML privileges, both the initial install and the first startup after an upgrade will fail with permission errors in tomcat/logs/jahia.log.

📌 Side Note: Module-level schema changes

The DDL privileges described above are not only needed for the Jahia core platform — many optional/enterprise modules also ship their own database schema and evolve it automatically whenever the module is installed or upgraded. A known example is Remote Publishing, which maintains its own journal tables in the database to track replicated events; these tables are created/altered at module deploy time using the same JDBC connection as the rest of Jahia.

Implication: the DB user’s DDL rights must remain in place not just during the initial Jahia install/upgrade, but for the full lifetime of the instance — any subsequent module install or upgrade (via the OSGi bundle deployment mechanism, GUI, or REST API) can trigger its own schema migration at that moment, without a separate elevated account. Do not narrow the DB user’s privileges back down to DML-only after the initial install/upgrade completes, as this will break module deployments later.

Answer

Recommended approach

  • Create a dedicated database/schema exclusively for Jahia (do not share it with other applications).
  • Grant the Jahia DB user full DDL + DML rights scoped to that database/schema only — do not reuse a shared DBA/root/sa account long-term, and do not grant server-wide/instance-wide privileges.
  • Keep the same privilege level for install, upgrade, and ongoing module deployments — no need to temporarily elevate to a DBA account for any of these; the regular Jahia DB user is sufficient if scoped correctly from the start, and it should stay that way permanently.

Per-database guidance

Database Minimum privilege scope Notes
MySQL / MariaDB ALL PRIVILEGES on the jahia schema (or explicitly: SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, DROP, INDEX, REFERENCES, CREATE VIEW, CREATE TEMPORARY TABLES, LOCK TABLES) Driver: com.mysql.cj.jdbc.Driver. Also confirm innodb_file_per_table=1, max_allowed_packet ≥ 100M, utf8mb4 charset/collation are set at the server level (separate from user privileges).
PostgreSQL Ownership of the schema (or CREATE + full DML), plus rights to use Large Objects (lo_import/lo_export/GRANT ... ON LARGE OBJECT) Jackrabbit stores binary content as PostgreSQL Large Objects. The user also needs rights to create the pgblobs view used for the VACUUMLO maintenance job (see install reference).
Oracle Own tablespace with UNLIMITED quota; CREATE SESSION, CREATE TABLE, CREATE VIEW, CREATE SEQUENCE, CREATE PROCEDURE (if applicable), plus implicit ALTER/DROP on objects it owns User should own its schema, not operate against someone else’s.
MS SQL Server db_owner role on the Jahia database (or the combination db_ddladmin + db_datareader + db_datawriter) db_owner is simplest since it covers all schema-evolution scenarios across upgrades and module deployments.

Common pitfalls

  • Restricting to DML-only → install wizard or post-upgrade startup fails with permission denied / ORA-01031 / Access denied errors in jahia.log.
  • Narrowing privileges back down after go-live → a later module install/upgrade (e.g., Remote Publishing) fails because it can no longer create/alter its own tables.
  • Reusing a DBA account in production → security risk; prefer a scoped, dedicated user even though the privilege level (DDL) looks similar to a DBA.
  • PostgreSQL large-object permissions overlooked → binary assets (images, files) fail to save even though regular table DML works fine.
  • Oracle tablespace quota set too low → installs succeed initially but later uploads/imports fail once quota is exhausted.

Related

  • Installation prerequisites and JDBC connection details: see the Jahia Installation Guide (system requirements, DB setup).
  • Upgrade execution: see the Jahia Upgrade Guide — the same DB user/privileges apply for rolling, in-place, and blue-green upgrade strategies; no separate “upgrade-only” DB account is needed.
  • Remote Publication configuration and troubleshooting: see the Platform Management Guide.