« Dolibarr config file content seems to be not correctly defined »

Le message « Dolibarr config file content seems to be not correctly defined » reproduit cause par cause sur Dolibarr 24 : ce que dit la parenthèse, le déménagement de serveur, le fichier disparu, les tâches planifiées, et pourquoi relancer /install sur une instance existante n'est pas anodin.

Versions concernées
Dolibarr 24.0.2 (archive officielle, installée par l'assistant web ; PHP 8.2) · même contrôle dans les versions plus anciennes, texte parfois sans parenthèse
Ce qui a été vérifié
Tests du 18/10/2026 sur une instance neuve de Dolibarr 24.0.2 : conf.php vide, ligne dolibarr_main_document_root mise en commentaire, conf.php absent, conf.php illisible, ancien chemin après déménagement (avec et sans open_basedir), functions.lib.php supprimé, erreur de syntaxe, barre finale dans le chemin ; script des tâches planifiées (scripts/cron/cron_run_jobs.php de l'archive 24.0.2) lancé sous deux comptes ; page /install avec et sans install.lock ; assistant d'installation relancé sur la base existante ; ancienne URL racine avec sous-dossier. Réponses HTTP relevées avec curl, pages relevées dans un navigateur, journal PHP lu. Lecture du code de Dolibarr 24.0.2 (filefunc.inc.php).

Vous ouvrez Dolibarr et la page ne contient que deux lignes en anglais :

Error: Dolibarr config file content seems to be not correctly defined (…).
Please run dolibarr setup by calling page /install.

Ce message ne dit pas que la base de données est abîmée. Il dit une seule chose : Dolibarr a bien trouvé son fichier de configuration conf/conf.php, mais en le lisant, il ne trouve pas son propre code. Tout le reste découle de ce qui est écrit entre parenthèses.

Chaque cas ci-dessous a été provoqué le 18 octobre 2026 sur une installation neuve de Dolibarr 24.0.2.

Lisez la parenthèse

Le message vient d’un seul test, dans filefunc.inc.php : Dolibarr lit la ligne $dolibarr_main_document_root de conf.php et vérifie qu’il existe un fichier core/lib/functions.lib.php à cet endroit. Deux versions du message en découlent.

Parenthèse Ce que ça veut dire Causes rencontrées
… can't be unknown) conf.php ne donne aucun chemin fichier vide ; ligne effacée ou mise en commentaire ; en ligne de commande, fichier illisible pour le compte qui lance le script
(file /un/chemin/… not found) le chemin est donné, mais le code n’y est pas Dolibarr a changé de dossier (déménagement, hébergeur qui renomme ses dossiers) ; ou le fichier a disparu

Sur les versions plus anciennes, la parenthèse peut manquer : le diagnostic ci-dessous reste le même, il faut simplement ouvrir conf.php pour savoir dans quel cas vous êtes.

Cas 1 : « can’t be unknown », le fichier ne donne pas de chemin

Ouvrez htdocs/conf/conf.php (d’après le code, les paquets Debian et Red Hat le placent dans /etc/dolibarr/conf.php).

  • Le fichier est vide, juste après l’installation : c’est la situation des fils 49980 et 51134 du forum (le second avec le paquet .deb). Dans ce cas seulement, faites ce que dit le message : ouvrez l’adresse de Dolibarr suivie de /install (par exemple http://localhost/dolibarr/install) et suivez l’assistant. C’est ce qui a débloqué les deux personnes. Si Dolibarr était déjà utilisé, un fichier vide veut dire qu’il a été écrasé : reprenez celui de votre dernière sauvegarde (et lisez la section sur /install avant de relancer l’assistant).
  • Le fichier est rempli mais la ligne $dolibarr_main_document_root= manque ou commence par // : remettez-la, avec le dossier qui contient index.php et le dossier core. Nous avons provoqué l’erreur en ajoutant simplement // devant cette ligne.

Cas 2 : « file … not found », comparez le chemin

Regardez le chemin affiché, puis le vrai dossier de Dolibarr sur le serveur.

Le message quand conf.php désigne encore l’ancien dossier

Le chemin est différent : Dolibarr a été déplacé, ou l’hébergeur a changé l’organisation de ses dossiers (fils 51071 chez Free, 49565 après un changement de serveur). Corrigez les lignes de conf.php qui contiennent l’ancien chemin :

$dolibarr_main_document_root='/nouveau/chemin/htdocs';
$dolibarr_main_document_root_alt='/nouveau/chemin/htdocs/custom';
$dolibarr_main_data_root='/nouveau/chemin/documents';

Pour connaître le bon chemin sans accès SSH : ouvrez /install dans le navigateur. Même quand l’installation est verrouillée par install.lock, Dolibarr 24.0.2 affiche alors un avertissement qui donne les deux chemins : « You are running files from directory (/le/vrai/chemin/) that differs from the directory already defined into the existing conf.php file ». Nous l’avons vérifié avec le verrou en place.

Sur un hébergement mutualisé, le journal PHP montre souvent en plus un avertissement open_basedir restriction in effect. File(/ancien/chemin/…) is not within the allowed path(s) : même cause, même correction. Dans notre test, cet avertissement n’apparaissait que dans le journal du serveur, pas à l’écran.

Le chemin est le bon : c’est le fichier core/lib/functions.lib.php qui manque. Nous l’avons reproduit en le supprimant : le message affiche alors le vrai chemin. Causes possibles : une mise à jour ou un envoi FTP interrompu, ou un outil qui supprime des fichiers. Dans le fil 46065, le fichier disparaissait chaque matin et un antivirus trop zélé a été soupçonné, sans certitude. Correction : recopiez les fichiers de la même version de Dolibarr (archive officielle), sans toucher à conf/conf.php ni au dossier des documents, puis cherchez ce qui supprime le fichier.

Une barre finale dans le chemin (/var/www/html/) ne pose pas de problème : nous l’avons testée.

Ce qui ne donne pas ce message

Deux pannes proches s’affichent autrement, utile pour ne pas chercher au mauvais endroit :

  • conf.php absent ou illisible par le serveur web : pas de message, Dolibarr redirige vers /install. Si install.lock est présent, vous voyez alors « Les pages d’installation/mise à jour ont été désactivées pour des raisons de sécurité ». Voir install.lock et la page d’installation.
  • Une erreur de frappe dans conf.php (un guillemet oublié après une modification) : page blanche ou erreur 500. Le journal PHP indique PHP Parse error: syntax error … in …/conf/conf.php on line 16. Attention, la ligne citée est souvent celle qui suit l’erreur : dans notre test, le guillemet manquait ligne 15. Voir Erreur 500 ou page blanche.

Faut-il lancer /install comme le demande le message ?

Pour une installation neuve, oui. Pour un Dolibarr déjà utilisé, non, pas avant d’avoir compris la cause. Nous avons vidé conf.php, retiré le verrou et relancé l’assistant sur la base existante, avec les mêmes paramètres de base de données :

  • les données étaient toujours là (le tiers de test, le compte admin, avec son ancien mot de passe : l’assistant a seulement signalé « L’identifiant admin existe déjà ») ;
  • mais l’assistant a écrit un conf.php neuf, avec une nouvelle clé d’instance ($dolibarr_main_instance_unique_id). Les données que Dolibarr chiffre avec cette clé deviennent illisibles : dans notre test, le mot de passe SMTP enregistré n’était plus déchiffré, ce qui casse l’envoi d’e-mails (voir Dolibarr n’envoie pas les e-mails).

Remettre l’ancienne clé dans le nouveau conf.php a tout rendu lisible à nouveau. Si vous avez déjà relancé l’assistant, récupérez cette ligne dans une ancienne copie de conf.php (voir Sauvegarder et restaurer Dolibarr). Nous n’avons testé qu’une base de test presque vide : sur une vraie base, faites une sauvegarde avant toute chose.

Après un déménagement : la page de connexion sans mise en forme

Une fois le chemin corrigé, un second piège attend ceux qui changent d’hébergeur : la ligne $dolibarr_main_url_root. Si l’ancienne adresse contenait un sous-dossier (par exemple https://ancien-hebergeur/dolibarr/htdocs) et pas la nouvelle, la page de connexion s’affiche sans aucune mise en forme, et après connexion le navigateur arrive sur « Not Found ».

Page de connexion avec une ancienne URL racine

Mettez dans $dolibarr_main_url_root l’adresse exacte que vous tapez pour ouvrir Dolibarr, sans barre finale. Avec un simple changement de nom de domaine, sans sous-dossier, nous n’avons constaté aucun problème d’affichage, mais mettez-la à jour quand même.

Les tâches planifiées affichent l’erreur, pas le navigateur

Si le site marche mais que le message arrive par e-mail ou dans le journal du cron, c’est souvent une question de compte. Nous avons rendu conf.php lisible seulement par son propriétaire root : lancé sous le compte du serveur web (www-data), cron_run_jobs.php affichait « can’t be unknown » ; lancé en root, il fonctionnait. Faites tourner la tâche sous le compte qui peut lire conf.php, en général celui du serveur web (voir la ligne de cron du guide Installer Dolibarr sur Ubuntu ou Debian).

Si ça ne repart pas

Si le message persiste après ces vérifications, ou si vous n’avez pas de copie de l’ancien conf.php, le diagnostic à 90 € consiste justement à regarder votre instance avec vous pendant une heure, puis à vous remettre par écrit la cause et ce que coûterait la correction.

Dolibarrconfig filenot correctly definedconf.phpdolibarr_main_document_rootfunctions.lib.phpinstallmigrationchangement de serveuropen_basedircron