« 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.
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 exemplehttp://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/installavant 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 contientindex.phpet le dossiercore. 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 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.phpabsent ou illisible par le serveur web : pas de message, Dolibarr redirige vers/install. Siinstall.lockest 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 indiquePHP 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.phpneuf, 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 ».

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.