Forum

Bonjour,


Je sais que cette section n’a pas vocation a être du support pour la version Cauldron, mais je souhaite poser la question ici avant de créer un ticket de bug au cas ou je serais passer à côté d’un paramètre évident.
Si ce n’est pas approprié je m’en excuse par avance et je supprimerai le message.

Je rencontre une petite problématique pour la détection d’un ancien scanner canon (LiDE 20) dans Cauldron et uniquement pour l'utilisateur courant.
Les paquets installés sont :

• task-scanning
• sane-backends
• xsane
• lib64sane1
• ksanecore
• lib64ksanecore6_1
• libksane
  

La commande : voit un potentiel scanner :

Mais la commande ne détecte pas le scanner :
Cependant si j’utilise la même commande avec les droits « root » alors tout est bien fonctionnel.
Si je passe par le CCM, « Matériel », « Configurer le scanner », il est bien détecté également (Mais je suppose que c'est "root" donc normal).

En contrôlant les périphériques USB branchés avec la commande cela donne :


En parcourant plusieurs forums il s’avère que c’est un problème qui semble plutôt récurrent sur pas mal de distributions.
J’ai donc essayé diverses méthodes pour faire fonctionner le scanner (Ajout des droits scanner / lp pour mon utilisateur, contrôle des règles udev, vérification des fichier dans /sane.d afin de vérifier que « plustek » soit bien présent, qu’il y ait bien un ligne [usb] présente, ajout des informations du scanner directement dans le fichier plustek.conf, ajout des droits en direct sur le port USB ou est connecté le scanner… ) mais rien n’y fait, mon utilisateur ne peut pas accéder au scanner.

Dans le journal je peux voir ces lignes lorsque je connecte le scanner :

NB : Dans les options de la carte mère l’option « Legacy USB support » est bien active. Dans le doute l'option "XHCI hand-off" de la carte mère a été désactivé et activé pour être sûr également.


Sur autre PC avec Mageia 9 et après installation des mêmes paquets (a la seule différence que lib64ksanecore6_1 n'existe pas mais est lib64ksanecore1), le scanner est détecté et fonctionnel directement.

J’ai donc essayé de comparer les différences :
• Les droits dans les fichiers /etc/sane.d/* sont identiques, le contenu du fichier « plustek.conf » également.
• Les droits sur les fichiers dans /usr/lib/udev/rules.d/ et /lib/udev/rules.d sont identique, leurs contenus semblent également cohérent malgré quelques différences mais qui ne semble pas avoir d’incidence sur les droits/accès au scanner.
• Les droits sur /dev/bus/usb sont également identiques et la modification effectué lors du branchement du scanner donne le même résultat également niveau droits.
L’utilisateur sur ce poste n’appartient pas au groupe scanner ni lp, il n’est dans aucun groupe en fait.

Le seul écart constaté est au niveau de /var/lib/lock/sane :
Dans Mageia 9 le droit sur le dossier sane est total (777) avec un « sticky » : drwxrwxrwt
Alors que dans Mageia 10 le droit est plus restreint : drwxrwx---
Après modification rien n’a changé pour le scanner malheureusement.


Avez-vous une idée de ce que j’aurai pu louper ?
Et merci d'avoir prit le temps de lire.

Il faut ajouter un règle udev (udev.rules).

Peux-tu tenter:


puis recharger les règles udev:

Wow, je ne m'attendais pas à une réponse si rapide.
Déjà merci pour le retour !

J'avais déjà tenté de créer une règle dans /etc/udev/rules.d/ (Avec un autre nom) mais j'y ai renoncé suite à la comparaison avec Mageia 9 qui n'a aucune règle à cet emplacement.

je viens d'essayer (En supprimant l'ancienne règle créé). Et le résultat est le même.
J'ai reboot également dans le doute pour être sûr que tout se mette en place correctement.

Aha.

Peux tu donner le résultat de ces commandes:


J'aimerai bien proposé un ls -lisah sur /dev/, mais le résultat sera très long et je ne sais pas sur quoi filtrer pour voir le fichier.

dans ton premier poste, as tu débranché et rebranché le périphérique sur un port USB différent ?

On peut essayer de retrouver le périphérique:

Désolé pour le délai de réponse, et merci pour les retours.
Je réponds à tous les messages à la suite :

Jybz :

Peux tu donner le résultat de ces commandes:

Le résultat de :
Le résultat de :
Le résultat de : monuser wheel vboxusers (J'ai retiré lp et scanner que j'avais ajouté lors des tests précédents)

Jybz :

dans ton premier poste, as tu débranché et rebranché le périphérique sur un port USB différent ?

Oui, j'ai testé sur différents ports USB. Lorsque je faisais des tentatives de droits / config, je débranchais / rebranchais et je relançais les services / sessions même si je pense que j'ai loupé à certains moments

Jybz :

On peut essayer de retrouver le périphérique:

Pour le résultat de la dernière commande :


Petit complément :
Lorsque je connecte / déconnecte le scanner, Plasma affiche une notification :

Donc il détecte bien et identifie bien le périphérique.

Bonjour,

Ceci me parait contradictoire.

Citation :

ATTRS{idVendor}=="04a9", ATTRS{idProduct}=="220d", MODE="0666", GROUP="users"

Citation :

monuser wheel vboxusers

ici la règle udev indique que les droits 666 sont valables si et seulement si l' utilisateur qui essaye d' ici accéder est dans le groupe users ce qui est contredit par l' appartenance au groupe.

Le mieux serait d' identifier le chemin du scanner dans /dev et regarder les droits qui s' y appliquent ( est ce que udevadm monitor permettrait de le voir ? en débranchant et rebranchant le scanner ?

edit: ceci dit faire un "sudo journalctl -f " dans une console en débranchant/branchant le scanner doit aussi permettre de voir cette information.

Édité par nic80 Le 14/03/2026 à 19h43

Merci pour votre retour.

nic80 :

ici la règle udev indique que les droits 666 sont valables si et seulement si l' utilisateur qui essaye d' ici accéder est dans le groupe users

Effectivement je n'ai pas bien regardé.
J'ai ajouté mon utilisateur dans le groupe "users" afin de vérifier.
Malheureusement, même comportement.

nic80 :

Le mieux serait d' identifier le chemin du scanner dans /dev et regarder les droits qui s' y appliquent

Si je comprends bien ce serait de regarder le droit lorsqu'on connecte le scanner sur le port en question ?
J'ai réalisé un sur /dev/bus/usb/001/
Si c'est ça, je l'ai comparé à Mageia 9 et il est identique, le résultat est le suivant :

La dernière ligne disparait lorsque je débranche le scanner.
Et suite a ce constat, j'avais essayé d'ajouter le groupe scanner mais sans succès non plus.
J'ai repris le script dans /etc/udev/rules.d/50-canoscan.rules pour essayer avec le groupe scanner à la place de users également et en ajoutant mon utilisateur à nouveau dans le groupe scanner, il n'est toujours pas détecté.

Voici le résultat de la commande

Lorsque je connecte le scanner :


Lorsque je déconnecte :


En utilisant la commande
Branchement :


Débranchement :

Bonjour,

Malheureusement pas sur que le udevadm monitor ou le journalctl apporte quelque chose (on sait juste que le scanner est trouvé et le udevadm indique son chemin potentiel (mais comment le trouver réellement dans l' arborescence de /dev ?

Le petit + à la fin du ls pour le fichier scanner est aussi présent sous Mageia 9 ? Sinon il y a des acls supplementaires dessus getfacl permet de voir ce que cela dit (le user doit aussi apparaitre eventuellement).

Aussi est ce que les permissions sur /lib/sane sont les mêmes ( si Sane ne peut pas charger ses modules, forcément le scanner ne peut pas être trouvé.

Je me demande si l' option -v de scanimage donne des resultats particuliers (en principe ç' est le mode verbeux).

Edit : le sane-find-scanner esr lancé en root ou en utilisateur normal (un sane-find-scanner -v devrait dire sur quel periphérique le scanner est trouvé (ou pas) ?

Edit 2: si sane-find-scanner voit le scanner sur un chemin particulier, peut être peut on l'indiquer à scanimage (scanimage -d /dev/usb/scanner par exemple) ?

Édité par nic80 Le 14/03/2026 à 23h18

Bonjour Rick,
Bravo pour toutes les infos que tu transmets et ce que tu as déjà essayé.
La question semble tourner autour de la question des droits d'accès.
Cependant, as-tu fait fonctionné le scanner en root, jusqu'à obtenir une image ? je crois que c'est scanimage -T
Pour y voir plus en détail l'origine du problème, je propose la méthode suivante :
installer strace
lancer :
strace -e open,read,write sane-find-scanner 2>strace.txt
Tu récupères un fichier strace.txt avec l'analyse de strace. Tu peux le regarder et nous le fournir. Ceci pourrait identifier les canaux qui sont inaccessibles en lecture ou écriture.
La comparaison de la même sortie avec l'utilisateur root pourrait aussi relever les différences de droits d'accès.