When Duplicator refuses to cooperate
I’m loading a production WordPress backup locally via Duplicator Pro. Backup is 60 GB (database + media). The installer starts, looks fine, click Next – and dies at the DB Install stage with the message:
EXCEPTION ERROR: SESSION variable 'max_allowed_packet'
is read-only. Use SET GLOBAL to assign the value
FILE: .../dup-installer/classes/database/class.db.php[633]
Google full of queries “how to fix this”. No sensible answer.
The reason is specific: Duplicator Pro 4.0.5.3 (and earlier) tries at session start to set SET SESSION max_allowed_packet, so it can import large single database records. From MariaDB 10.5 this variable is marked as read-only at the session level – it can only be changed globally, as an administrator with the right permissions.
Duplicator doesn’t know this and tries to set it anyway. MariaDB throws an exception. The installer stops.
Three things to do
1. Increase max_allowed_packet globally in the MariaDB config
Since it can’t be set per session, set it once at the global level in the server config. On XAMPP edit the file:
c:/xampp/mysql/bin/my.ini
In the [mysqld] section add (or find and change):
[mysqld]
max_allowed_packet = 256M
Restart MySQL in the XAMPP panel. From now on every session has a large enough packet and Duplicator doesn’t need to change it per session.
Verify it worked: open phpMyAdmin (localhost/phpmyadmin) → SQL tab and paste:
SHOW GLOBAL VARIABLES LIKE 'max_allowed_packet';
You should see the value 268435456 (that’s 256M in bytes). If it still shows a low value (e.g. 16777216 = 16M), the MySQL restart didn’t catch – check if the my.ini file you edited is really the one used by the running XAMPP instance.
2. Comment out the problematic lines in Duplicator
Even with global config Duplicator STILL TRIES to set it per session – and still gets the error. It needs to be discouraged from trying.
Open the file:
dup-installer/ctrls/classes/class.ctrl.dbinstall.php
Find the lines (in my case 565-566, in yours they may be slightly different depending on Duplicator version):
DUPX_DB::mysqli_query($this->dbh, "SET GLOBAL max_allowed_packet = ...");
DUPX_DB::mysqli_query($this->dbh, "SET max_allowed_packet = ...");
Comment out both:
// DISABLED - MariaDB 10.5+ blocks SET SESSION max_allowed_packet.
// DUPX_DB::mysqli_query($this->dbh, "SET GLOBAL max_allowed_packet = ...");
// DUPX_DB::mysqli_query($this->dbh, "SET max_allowed_packet = ...");
Save the file. Run the installer again.
3. Bonus: turn off display_errors in PHP
If you’re using XAMPP with PHP 8.1 or newer, additionally Duplicator can fail on deprecation warnings. PHP spits warnings BEFORE sending HTML, causing the installer response to contain a pile of warning text at the start instead of clean JSON or HTML. The installer chokes on this.
Open the PHP config file:
c:/xampp/php/php.ini
Find the display_errors line and set it to Off:
display_errors = Off
Restart Apache in the XAMPP panel. Warnings still go to logs (that’s where they always go), but stop polluting the HTTP output.
Long-term solution
The above are workarounds. The real solution is:
- Update Duplicator Pro to version 4.5+ – newer versions know about MariaDB 10.5 and don’t try SET SESSION max_allowed_packet. If you have a license, just update.
- Consistently update the server hosting the source backup – so production exports are made with a newer Duplicator version generating newer installers.
But if right now you’re sitting with a 60 GB backup and the production server runs old Duplicator, and you have to set this up locally in an hour – the above three steps work.
Why does this happen at all
MariaDB 10.5 (October 2020) introduced a tightening of security policy. System variables that could affect server behavior per session – like max_allowed_packet – were marked as “GLOBAL only”. Session can read them, but can’t change them.
This makes sense from a security standpoint – otherwise a regular MySQL user could set a 4 GB packet size and overload the server. But it breaks older tools that assumed SET SESSION would always work.
Duplicator is one such tool. WP-CLI had the same problem for a while too. Many migration scripts based on mysqldump had the same.
Summary
Three file changes solve the case:
- my.ini – max_allowed_packet globally, restart MySQL
- class.ctrl.dbinstall.php – comment out 2 SET SESSION lines, save
- php.ini – display_errors Off, restart Apache
If you’re searching now at midnight for this exact error before tomorrow’s deadline – you now have all 3 fixes to copy and paste.



