Page de login en boucle suite à restauration debian 12 + restauration backup

Bonjour,

J’ai voulu passé mon Atlas de debian 11 à 12 sur mon jeedom 4.6.1 en utilisant la méthode manuelle en mettant JeedomSystemUpdate.img.gz dans le dossier /install/update de Jeedom (fichier JeedomAtlas-4.6.1_Bookworm-12.14.img.gz.

Cela s’est bien passé (Reboot, Changement d’IP, remise de l’IP correcte sur le routeur, reboot, premier login et changement de mot passe ok)

La remise en place de la sauvegarde s’est également bien terminée.

Par contre, je n’arrive plus à me loguer suite au dernier reboot.
J’ai un retour systématique à la page de login, sans message d’erreur. J’en ai un si je me trompe user/pwd.

La console Firefox me donne une erreur 500 Internal Server Error.

XHRPOST
http://192.168.1.7/core/ajax/user.ajax.php
[HTTP/1 500 Internal Server Error 76ms]
POST
scheme
	http
host
	192.168.1.7
filename
	/core/ajax/user.ajax.php
Adresse
	192.168.1.7:80
État
500
Internal Server Error
VersionHTTP/1
Transfert1,88 Ko (taille 0 o)
Politique de référentno-referrer
Priorité de la requêteHighest
Résolution DNSSystème
	
Access-Control-Allow-Headers
	origin, x-requested-with, content-type
Access-Control-Allow-Methods
	PUT, GET, POST, DELETE, OPTIONS
Access-Control-Allow-Origin
	*
Cache-Control
	no-store, no-cache, must-revalidate
Connection
	close
Content-Length
	0
Content-Security-Policy
	default-src 'self' file: data: blob: filesystem:;script-src-attr 'self' 'unsafe-inline' 'unsafe-eval' *.google.com *.google.fr *.googleapis.com *.openstreetmap.org;script-src 'self' 'unsafe-inline' 'unsafe-eval' *.google.com *.google.fr *.openstreetmap.org;script-src-elem 'self' 'unsafe-inline' 'unsafe-eval' *.google.com *.google.fr *.openstreetmap.org;img-src 'self' * data:;style-src 'self' 'unsafe-inline';style-src-attr 'self' 'unsafe-inline';worker-src blob:;frame-src 'self' *.jeedom.com *.google.com *.google.fr *.googleapis.com *.openstreetmap.org data:;
Content-Type
	application/json
Date
	Sat, 17 Oct 2026 18:46:24 GMT
Expires
	Thu, 19 Nov 1981 08:52:00 GMT
Permissions-Policy
	accelerometer=(),battery=(),fullscreen=(self),geolocation=(),camera=(),ambient-light-sensor=(self),autoplay=(self)
Pragma
	no-cache
Referrer-Policy
	strict-origin-when-cross-origin
Server
	Apache
X-Content-Type-Options
	nosniff
X-Frame-Options
	sameorigin
X-XSS-Protection
	1; mode=block
Accept
	*/*
Accept-Encoding
	gzip, deflate
Accept-Language
	fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3
Connection
	keep-alive
Content-Length
	83
Content-Type
	application/x-www-form-urlencoded; charset=UTF-8
Cookie
	PHPSESSID=aa6be9eunndo2h4m8301asf6mf9eaqnb6eeoj2i29vppuiho81ttgeirch80idq7
Host
	192.168.1.7
Origin
	http://192.168.1.7
Priority
	u=0
User-Agent
	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:140.0) Gecko/20100101 Firefox/140.0

J’ai toujours un accès SSH.
Le http.error donne

[Sat Oct 17 20:22:38.430024 2026] [php:error] [pid 526:tid 526] [client 192.168.1.41:52451] 
PHP Fatal error:  Uncaught TypeError: fwrite(): Argument #1 ($stream) must be of type resource, bool given in /var/www/html/core/class/log.class.php :120\nStack trace:\n#0 /var/www/html/core/class/log.class.php(120): fwrite()\n#1/var/www/html/core/class user.class.php(149): log::add()\n#2 /var/www/html/core/ajax/user.ajax.php(50): user::connect()\n#3 {main}\n  thrown in /var/www/html/core/class/log.class.php on line 120

Qu’ai-je fait de travers et comment réparer ce soucis de login?

Merci pour votre aide.

Salut,

Ca sent le plugin incompatible debian 12.

Est ce que la page rescue fonctionne ?

http://IPJEEDOM/index.php?rescue=1

Si oui, tu as une commande dans la partie BDD pour désactiver tous les plugins. Ensuite en les réactivant un par un tu va trouver le fautif …

Mais curieusemet le http.error donne des infos sur le core et pas sur un plugin en particulier …
Dans tous les cas j’essaierai déja de voir si le mode rescue marche ou non.

http://192.168.1.7/index.php?v=d&rescue=1

ne marche pas. Retour au login.

Puisque tu as accès en SSH, que donne

php jeecli.php user list

Lancé depuis le répertoire html/core/php depuis la racine de jeedom.

Tu es certain que la restauration du backup est allée jusqu’au bout sans erreur ?
Tu peux partager le log restore ?

J’ai bien ma liste d’utilisateur.
J’en ai même créé un nouveau pour voir mais idem.

 cat restore
[START RESTORE]
***************Begin Jeedom restore 2026-10-17 18:34:31***************
Send begin restore event...OK
Checking rights...OK
Restore from file : /var/www/html/core/class/../../backup/backup-Jeedom_Atlas-4.6.1-2026-10-17-17h20.tar.gz
Backup database access configuration...OK
Disable all task OK
Disable all scenario OK
Unpacking backup...OK
Update composer file...
OK
[PROGRESS][58]
Deleting database...Disabling constraints...OK
Deleting table : cache ...OK
Deleting table : cmd ...OK
Deleting table : config ...OK
Deleting table : cron ...OK
Deleting table : dataStore ...OK
Deleting table : eqLogic ...OK
Deleting table : event ...OK
Deleting table : history ...OK
Deleting table : historyArch ...OK
Deleting table : interactDef ...OK
Deleting table : interactQuery ...OK
Deleting table : listener ...OK
Deleting table : message ...OK
Deleting table : note ...OK
Deleting table : object ...OK
Deleting table : plan ...OK
Deleting table : plan3d ...OK
Deleting table : plan3dHeader ...OK
Deleting table : planHeader ...OK
Deleting table : queue ...OK
Deleting table : scenario ...OK
Deleting table : scenarioElement ...OK
Deleting table : scenarioExpression ...OK
Deleting table : scenarioSubElement ...OK
Deleting table : timeline ...OK
Deleting table : update ...OK
Deleting table : user ...OK
Deleting table : view ...OK
Deleting table : viewData ...OK
Deleting table : viewZone ...OK
Deleting table : widgets ...OK
Restoring database from backup...OK
Enable back constraints...OK
Restoring cache...OK
 Restoring Plugin: calendar...OK
sudo: yarn: command not found
PHP Warning:  Trying to access array offset on value of type null in /var/www/html/core/class/system.class.php on line 421
PHP Warning:  Trying to access array offset on value of type null in /var/www/html/core/class/system.class.php on line 431
Check jeedom consistency...[START CONSISTENCY]
[START CHECK AND FIX DB]
[END CHECK AND FIX DB]
Check jeedom package...ls: cannot access '/tmp/jeedom_install_in_progress*': No such file or directory
warning: commands will be executed using /bin/sh
job 2 at Sat Oct 17 18:36:00 2026
OK
Check jeedom database...OK
Check crons...

Check filesystem right...OK
Check jeedom object...OK
Check jeedom cmd...OK
Set cache hour...OK
Check composer...OK
Check nodejs...E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 4398 (apt)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?
npm warn using --force Recommended protections disabled.
Hit:1 http://deb.debian.org/debian bookworm InRelease
Hit:2 http://deb.debian.org/debian bookworm-updates InRelease
Hit:3 http://security.debian.org/debian-security bookworm-security InRelease
Hit:4 https://deb.nodesource.com/node_22.x nodistro InRelease
Reading package lists...
[Check Version NodeJS actuelle : v22.23.1 : [  OK  ]
[Check Prefix : /usr and sudo prefix : /usr and www-data prefix : /usr : [  OK  ]
Clean npm cache
OK
Check apache security file...[END CONSISTENCY]
OK
Enable scenario : OK
Enable task : OK
Check Network Conf : OK
Sending end restore event...OK
Restore duration : 144s
***************Jeedom Restore End***************
[END RESTORE SUCCESS]

Ok ben la du coup je sais pas quoi te faire checker de plus étant donné que je n’utilise pas les images jeedom …

Peut être quelqu’un aura une autre idée.

Si peut être juste un dernier truc : au cas ou tu as essayé d’ouvrir ton jeedom en navigation privée sur ton navigateur ?

Oui, j’ai testé la navigation privé.
Je vais quand même regardé avec un autre navigateur : Idem! Il y a 4 tentatives avec erreur 500.
Merci quand même.
Au pire, je repousse une debian11 + backup et je revérifie les plugins.

Faut que je regarde comment on transfert un fichier en SSH…

Bonjour,

Que donne un df -h en ssh ?

 df -h
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
udev               1,9G       0  1,9G   0% /dev
tmpfs              385M    1,3M  384M   1% /run
/dev/mmcblk0p2      29G    6,0G   22G  22% /
tmpfs              1,9G       0  1,9G   0% /dev/shm
tmpfs              5,0M       0  5,0M   0% /run/lock
tmpfs              1,9G    6,9M  1,9G   1% /tmp
tmpfs              385M    8,0K  385M   1% /run/user/1000

Tu as essayé de redémarrer avant que je te donne des commandes ssh pour chercher plus loin ?

Oui, j’ai mis hors tension pendant 20 secondes deux fois.

Et z2m est HS : Rien ne marche en zigbee.

Avant de chercher un souci sur le système de fichier je t’invite à saisir ces 2 commandes l’une à la suite de l’autre en ssh :

sudo chown -R www-data:www-data /var/www/html
sudo chmod -R 775 /var/www/html

Si le login passe ensuite alors c’était juste un problème de droits. Si tu as une erreur à la saisie d’une de ces commandes il faudra la partager :wink:

J’ai pu me reloguer.

Cool ! Bon je ne m’explique pas ce problème de droits là tout de suite, je garde ce sujet en tête. Sinon pour z2m et les autres plugins, comme d’habitude suite à une restauration de sauvegarde il faut réinstaller les dépendances ou juste patienter si elles sont en gestion auto.

Merci beaucoup.
Je vais faire le tour de la domotique pour remettre tout d’équerre.

Je ne comprends pas trop ce qui a pu se passer. Je n’ai pas l’impression d’avoir fait autre chose que ce qui est marqué dans la doc.

Encore merci.

Dans l’absolu tout s’est passé conformément à la doc de restauration système :wink: C’est la restauration de sauvegarde qui semble avoir eu un impact pour une raison inexpliquée. Tu n’as rien à te reprocher du tout, d’autant plus que tu as fourni beaucoup d’informations utiles dès le 1er message de ce sujet :clap:

Bonjour
jeeHelp aurait pu aider à diagnostiquer voir résoudre ce genre de situations.

Any chance que cet outil ou similaire soit intégré nativement à Jeedom ?

Sauf erreur ce problème de droits est une première, ça reste 2 lignes de commande en ssh pour corriger au final. Faudrait que je jette un oeil en détail mais tu sais bien que l’équipe ne peut pas prendre en compte toutes les suggestions issues de développeurs tiers :wink: C’est bien aussi d’avoir différentes visions et propositions issues de développeurs sans forcément avoir besoin d’en intégrer une spécifiquement au core.

le souci c’est qu’un certain nombre d’utilisateurs(dont moi) ne connaissent pas les commandes ssh par cœur et il faut chercher comment restaurer une sauvegarde, comment rétablir des droits, checker la db, problème stockage,…
cet outil aide à la fois au diagnostique (particulièrement pratique si l’accès à l’interface est impossible) et permet aussi un tas d’actions (rétablissement des droits, restauration, sauvegarde,…).

il faut déjà y penser et le savoir, si tu n’était pas disponible rapidement, ce fil aurait peut être attendu plus longtemps avant d’être résolu.

Pas de souci je n’ai pas fermé la porte. Effectivement un outil ssh global ne semble pas être une mauvaise chose, au contraire. Encore aurait-il fallu identifier la cause du souci dans le cas présent, will see j’en garde bonne note.