Bonjour,
Depuis que je suis passé en version 12.0.2, j’ai une erreur lors de la sauvegarde de la base de données :
"Erreur : mysqldump: Error: ‹ Access denied; you need (at least one of) the PROCESS privilege(s) for this operation › when trying to dump tablespaces "
Je suis en hébergement OVH pour le site + pour la base de donnée.
PHP V7.4.8
Base : MySQL 5.6
Merci de votre aide.
Le mysqldump est lancé depuis l’interface dolibarr ou en direct sur la machine ?
Je dirai un problème de droit sur la Base dolibarr. Si tu as accès à la machine qui héberge la BDD, tu peux faire un essai avec le compte dolibarr, sinon essaie avec le compte root.
Bonjour,
Désoler pour le manque de réactivité. Je n’ai toujours pas réussi à faire ma sauvegarde.
Je suis depuis l’interface WEB. Je n’ai pas accès physiquement à la machine qui héberge le site et la base, car c’est sur un hébergement mutualisé…
J’ai lu que cette erreur peut être corriger avec la commande --no-tablespaces mais en l’insérant dans la requête, j’ai la même erreur.
Je n’avais pas fait attention, mais mal grès le message d’erreur, il génère parfois un fichier.
Il me créer bien un DUMP, la taille du fichier semble correcte. Mais je ne sais pas si la sauvegarde est viable du coup…
Il faut ouvrir le fichier, il doit être de la forme :
-- MySQL dump <VERSION> Distrib <VERSION>-MariaDB, for debian-linux-gnu (x86_64)
--
-- Host: <BDDHOST> Database: <BASE>
-- ------------------------------------------------------
[...]
DROP TABLE IF EXISTS `llx_accounting_account`;
/*!40101 SET @saved_cs_client = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `llx_accounting_account` (
`rowid` bigint(20) NOT NULL AUTO_INCREMENT,
`entity` int(11) NOT NULL DEFAULT 1,
`datec` datetime DEFAULT NULL,
`tms` timestamp NOT NULL DEFAULT current_timestamp() ON UPDATE current_timestamp(),
`fk_pcg_version` varchar(32) NOT NULL,
`pcg_type` varchar(20) NOT NULL,
`account_number` varchar(32) NOT NULL,
`account_parent` int(11) DEFAULT 0,
`label` varchar(255) NOT NULL,
`labelshort` varchar(255) DEFAULT NULL,
`fk_accounting_category` int(11) DEFAULT 0,
`fk_user_author` int(11) DEFAULT NULL,
`fk_user_modif` int(11) DEFAULT NULL,
`active` tinyint(4) NOT NULL DEFAULT 1,
`reconcilable` tinyint(4) NOT NULL DEFAULT 0,
`import_key` varchar(14) DEFAULT NULL,
`extraparams` varchar(255) DEFAULT NULL,
PRIMARY KEY (`rowid`),
UNIQUE KEY `uk_accounting_account` (`account_number`,`entity`,`fk_pcg_version`),
KEY `idx_accounting_account_fk_pcg_version` (`fk_pcg_version`),
KEY `idx_accounting_account_account_parent` (`account_parent`),
CONSTRAINT `fk_accounting_account_fk_pcg_version` FOREIGN KEY (`fk_pcg_version`) REFERENCES `llx_accounting_system` (`pcg_version`)
) ENGINE=InnoDB AUTO_INCREMENT=17001 DEFAULT CHARSET=utf8mb4;
/*!40101 SET character_set_client = @saved_cs_client */;
--
-- Dumping data for table `llx_accounting_account`
--
LOCK TABLES `llx_accounting_account` WRITE;
/*!40000 ALTER TABLE `llx_accounting_account` DISABLE KEYS */;
INSERT INTO `llx_accounting_account` ...
[...]
-- Dump completed on 2020-12-06 21:05:27
Si tu as ce début et cette fin, je pense qu’on peut conclure que ton fichier est correct.
La table en exemple est « droppée » (=supprimée), créée, « lockée » (=verrouillée), les données insérées.
Au niveau du « INSERT » tu vas retrouver toutes les données que tu as mises dans dolibarr.
depuis la version 5.7.31 il faut maintenant des droits spécifiques :
This change affects users of the mysqldump command, which accesses tablespace information in the FILES table, and thus now requires the PROCESS privilege as well. Users who do not need to dump tablespace information can work around this requirement by invoking mysqldump with the --no-tablespaces option. (Bug #30350829)
les solution sont donc soit de donner les droits à l’utilisateur (ce qui n’est pas recommandé) , soit de lancer la commande de sauvegarde avec l’option --no-tablespaces.
comment fait-on pour modifier la commande en ligne sous-jacente quand on lance le backup depuis dolibarr ? si quelqu’un a la solution …
Hello,
pour ajouter l’option --no-tablespaces, une des solutions est de modifier le fichier /htdocs/core/class/utils.class.php pour y changer la ligne 290 de :
$param .= " --default-character-set=utf8"; // We always save output into utf8 charset
en
$param .= " --default-character-set=utf8 –no-tablespaces"; // We always save output into utf8 charset
comme toujours, on aura pris soin avant la modification de sauvegarder une version originale.
Etant donné qu’on modifie un fichier de base, toute mise à jour est susceptible d’écraser cette modification.
Bonjour et merci @doli32
Pouvez vous proposer votre correction sur GitHub que les Devs s’occupent de l’intégrer ?
@+
@Philazerty : c’est fait : Backup error when dealing with older mysql version · Issue #16100 · Dolibarr/dolibarr · GitHub
Bonjour,
Je viens de faire la modification du fichier utils.class.php.
Mais j’ai cette erreur maintenant (pour info je suis en version MYSQL v.5.6) :
« Erreur : Échec de l’exécution de la commande externe. Vérifiez qu’elle est disponible et exécutable par votre serveur PHP. Si le Safe Mode PHP est actif, vérifiez que la commande se trouve dans un répertoire défini dans le paramètre safe_mode_exec_dir. »
Est-ce que j’ai mal fait quelque chose ?
quand tu cliques sur générer sauvegarde tu as dessous la commande qui s’exécute :
Voici la ligne de commande qui apparait sous le bouton de génération :
/usr/bin/mysqldump xxxxxx -h xxxxxxx.mysql.db -u xxxxxxx -P 3306 -l --single-transaction --add-drop-table=TRUE --tables -c -e --hex-blob --default-character-set=utf8 –no-tablespaces -p"***********"
tu confirmes les 2 tirets devant le no de no tablespaces ?
si je devais epeler :
tiret tiret no tiret tablespaces
Bien vue !
Alors pour être précis, j’ai repris le texte de votre précédent post.
Et au lieu d’un double tiret, cela doit être un caractère spécial car il n’est pas sécable…
Je l’ai remplacé par un double tirer « – » et cela à corrigé le problème.
Je ne sais pas si c’est mon navigateur qui a remplacé tes tiret tiret par le symbole, mais le copier coller ne met pas deux caractères tiret, mais un autre symbole…
En tous cas, la sauvegarde fonctionne de nouveau. Merci beaucoup.
non, à priori c’est l’éditeur du forum qui fait ça.
Tant mieux si le problème est résolu.
Bonjour.
J’ai le même problème sur une 13.01 fraichement installée
/usr/bin/mysqldump ******** -h **********.mysql.db -u ********* -P 3306 -l --single-transaction --add-drop-table=TRUE --tables -c -e --hex-blob --default-character-set=utf8 -p"***********"
il semble que le –no-tablespaces ait disparu…
Effectivement :: ligne 287 utils.class.php
$param .= " --default-character-set=utf8"; // We always save output into utf8 charset
Bonsoir,
Je pense même qu’il n’a jamais été intégré, je viens de faire une pull request, à suivre, je vous tiendrais au courant sur ce fil de discutions.
PS pour que l’éditeur du forum génère correctement les -- il faut bien penser à encadrer votre code avec les `` (créé par la combinaison de touche ALT+7)
Cordialement,
Gaëtan.
Bonsoir,
pull request merged 
en plus clair la proposition a été acceptée elle sera donc dans la prochaine version de Dolibarr.
Cordialement,
Gaëtan.
@gmilad bug signalé le 29 janvier, qu’as tu fait que j’aurais raté pour que ce soit pris en compte ?
merci
Bonjour @doli32,
J’ai fait une Pull Request sur le GitHub avec la modification à apporter en citant ton issue et ce fil de discutions.
Si tu as le compétence/le temps et lorsque tu as testé sur différentes versions et que la correction que tu propose a été reprise avec succès par d’autres personnes, au lieu de faire une issue tu peux directement faire une Pull Request comme ça @eldy ou d’autres la regarde et si elle est correct et respect le bonne pratique de développement de Dolibarr alors en elle intégrée 
Amicalement,
Gaëtan.
