Reprise du message précédent :
Je vais creuser. En ligne de commande avoir un truc le plus simple et intègré à l’OS mais peut être que ça ne change rien

Mon serveur de backup s'allume tous les matins, monte un partage NFS sur mon serveur principal, fait une backup et s'éteint.
 
Depuis début octobre, dans environ 25% des cas le montage du partage NFS plante, le serveur refuse l'accès. Ce genre de problème parle à quelqu'un ?

 
quand il se réveille il récupère bien la bonne adresse réseau (v4 ou v6) ?

oui
il est en IPv6 only, IP fixe configurée dans /etc/network/interfaces, on pourrait difficilement faire plus simple de ce côté là

que disent les logs ?

lesquels ?

Tout ce que je trouve c'est dans le /var/log/syslog côté client, ceci : "access denied by server" au boot au moment de monter le répertoire listé dans fstab

et cote server ?
journalctl ou dans /var/log/nfs ou dmesg ?

journalctl :

/var/log/nfs n'existe pas

dmesg n'a pas l'air de remonter à plus de 4h (en tout cas c'est ce que je constate avec dmesg -H)

C'est bizarre pour dmesg.
 
Le truc c'est que si cela marche parfois et pas tout le temps, soit il y a une modif quelque part, par exemple une maj automatique sur le server ou le client et un probleme de version (peu probable), soit le réseau n'est pas init mais si à chaque fois le serveur répond bien c'est pas vraiment ça.
 
En solution simpliste, je dirais de ressayer de lancer le script 5mn après

ça ne changerait rien, le script teste déjà régulièrement pour voir si le mount est actif (parfois ça met 2-3 minutes), avant d'abandonner au bout de 15 minutes. Mais ma compréhension est que l'access denied au boot est considéré comme une erreur définitive par le client (ce qui me paraît logique), donc ça ne sert à rien d'attendre dans ce cas.
 
en solution "bricolage", il faudrait que le script tente lui-même de refaire le mount mais actuellement ce n'est pas le cas, on se base sur le montage automatique au boot avec fstab (ce qui permet que le script n'ait pas de privilège particulier)

[edit]si le probleme est sur le mount de fstab, est ce que tu peux reproduire manuellement l'erreur ?

Ce qui est troublant, c'est que le serveur dit que y a pas d'export pour ce client/cette IP...

Que dit un exportfs -v exécuté à ce moment là sur le serveur ? (Quitte à le cron-er pour avoir l'info dans un log si t'es pas sur la machine)

Tu peux aussi décaler le job de backup pour qu'il se lance à un moment où t'es dispo pour diagnostiquer, ça peut aider.

 
non
 
d'ailleurs si depuis le client on retente le mount manuellement (en se basant sur l'entrée fstab), ça fonctionne
 
et à part ça depuis mon desktop j'ai le même mount que je monte (en full manuel) tous les jours, ça fonctionne à chaque fois.
 

 
Je peux faire ce que je veux sur le serveur pas de souci, mais il faut faire quoi exactement ? un exportfs -v à peu près au même moment que le client tente de faire le montage ? Sachant que je peux difficilement savoir à la seconde près quand ça va arriver, et qu'en plus le problème ne se présente qu'une fois sur 4 environ.

 
C'est à dire que si le client n'arrive pas à se connecter et que tu relance un mount plus tard, cela fonctionne ?

Ben tu le mets dans un cron qui s'exécute quelques minutes avant le lancement de ton backup.
Ou tu le fais via une commande ssh dans ton script de backup.
Et le jour où t'as le souci tu check tes logs.

Y'a peut être un nouveau noyau qui est en train d'arriver sur les backports non ?

Le 6.16 est dispo sur trixie-backports : https://packages.debian.org/trixie- [...] mage-amd64

Oui mais je veux dire je crois y'a le 6.16.12 qui va se pointer...

 
J'ai pu essayer une fois donc je ne peux pas en faire une généralité, mais oui en retentant de lancer la mount manuellement (commande mount qui référence l'entrée fstab) plus tard, le montage a bien fonctionné.
 

 
Ok j'ai mis un cron en place, on verra ce que ça donne

 
ça fait penser à une « race condition » tes symptômes. Tu as bien _netdev dans les options de montage ?

Ah les "race condition", le genre de truc sympa à débugger...  
 
Sinon, pour ceux qui auraient des soucis de son (craquements, grésillements; sortie analogique) sous Debian 13 quand Firefox a tourné un bon moment: sudo apt remove/purge speech-dispatcher (évidemment ça enlève la possibilité d'utiliser la synthèse vocale(?) ).

Encore moi et désolé si j'ai déjà posé la question
 
Je viens de faire la désagréable découverte que la nouvelle version (?) Anydesk coupe la connection au bout de 15 min au lieu d'une heure et je vais pas payer presque 30€ tout les mois pour pouvoir dépanner des proches...  
 
Une alternative? J'avais entendu parler de Rustdesk, mais leur site ne charge même pas chez moi, problème TLS. Et ça inspire confiance: https://www.ssllabs.com/ssltest/ana [...] ismatch=on
 
Teamviewer avait de gros soucis à mon moment, les accents ne passaient pas, sans dire que vu le monde je préfère largement un truc européen ou - au mieux - FLOSS... Perso je peux bricoler un peu, mais faut que au final ça soit simple à utiliser, genre au pire un code à communiquer par téléphone / un clic "autoriser la connection" au niveau du PC distant.

Teamviewer de mémoire c'est comme Anydesk, c'est payant.
 
Rustdesk j'ai eu essayé de l'utiliser il y a quelques temps.
 
ça marche pas trop mal tant que t'es pas sous Wayland (à tester avec les versions récentes).

Teamviewer il existe(ait??) une version gratuite aussi.

Je vais (devoir) tester Rustdesk, mais il faudrait qu'ils réparent leur site web déjà...

Je suis sous X11 toujours comme j'utilise Xfce; idem pour le poste distant.

EDIT: Ca commence bien, Rustdesk n'est pas dans les dépôts Debian... (m'enfin de toute façon la version aurait été vieille comme le monde) Vais voir si ils sont sur github ou autre où on peut trouver un .deb.

Y avait https://meshcentral.com/ me semble que c'était fait par un tech intel si je me rappelle bien. Par contre c'est plus compliqué à mettre en place.
Rust desk c'était le souvent plébiscité en général.

Pour rust desk autant aller voir sur le gitlab directement:
https://github.com/rustdesk/rustdesk

Oui merci, j'ai déjà le .deb sur SSD; mais faut que j'installe une VM Debian 13 (en cours) pour tester sans risques...

pour un test rapide, il est sur flathub

Premier test rapide: RAS.
 
Installation du .deb sans problème sous Debian 13 Xfce (VM), configuration très simple (ils se sont vachement inspirés d'Anydesk ) et j'ai pu piloter une VM depuis une autre.
 
Je pense que je vais installer ça en parallèle de Anydesk sur le PC de mon proche.

Dites j'ai modifié le fichier de conf de grub
Mais "update-grub" ne fonctionne pas comme si la commande n'existait pas ?
Et je trouve rien sur internet

whereis update-grub ?
ou update-grub2
/usr/sbin/update-grub ?

« update-grub » n’est normalement qu’un alias vers « grub-mkconfig -o /boot/grub/grub.cfg ». Cette dernière commande doit fonctionner. Sinon, c’est que tu n’utilises pas Grub mais un autre système d’amorçage (systemd-boot ?).

froggycorp : « grub2 », c’est le nom utilisé sur Fedora.

normalememnt sous debian:

 
et c'est un script bash qui fait un

 
et il faut bien sur etre root pour utiliser cette commande
 
ca te donne quoi comme retour quand tu fais un update-grub ?

voila, t'as peut etre systemd-boot. mais sous debian c'est pas encore par défaut (heureusement)

T'étais bien root?

Coucou  
 
ceci fonctionne
 
grub-mkconfig -o /boot/grub/grub.cfg
 
C'est un problème d'alias ou je sais pas quoi
 
Bref c'est résolu ?

Bonjour

J'ai une question au sujet Armbian/Debian version desktop (Cinnamon) et xrdp (remote desktop).

Quand j'essaye de me connecter dessus via Windows, j'ai un écran vide (bleu clair). Bref le bureau ne se charge pas.

Alors j'ai essayé d'arranger ça avec l'aide de copilote, mais rien y fait ça ne veut pas tomber en marche.

Bref je dois configurer quelque chose en particulier?

 
Vérifie que :
 
$ sudo cat /usr/sbin/update-grub
#!/bin/sh
set -e
exec grub-mkconfig -o /boot/grub/grub.cfg "$@"
 
 
et si cela répond :
 
$ ls -al /usr/sbin/update-grub
-rwxr-xr-x 1 root root 64  3 juil. 18:35 /usr/sbin/update-grub

 
C'est fait, j'ai eu 2 nouveaux échecs depuis, le exportfs -v donne le même résultat tout le temps.
 

 
non, je ne connais pas cette option, pour le moment j'avais ça :
 

 
j'ai rajouté _netdev, on va voir si ça change quelque chose.