not authorized to perform opération

hibou7 · Le 16/02/2020, à 01:53

Salut Cédric

J'ai touvé quelque chose sur le message d'erreur
"Not authorised to perform operation (udisks-error-quark, 4)"
https://bbs.archlinux.org/viewtopic.php?id=180765
Pourrais-tu vérifier si gvfs est bien installé sur ton système?

Sinon il y aurait ntfs-config (cf. #15).

cedricgfr · Le 16/02/2020, à 08:51

Bonjour,
gvfs est bien installé.
Quant au post #, rien de permanent.

Merci quand même.

moko138 · Le 16/02/2020, à 10:08

Désolé, je n'avais pas cu ton #24.

La clef et sa partition sont reconnues (à 8 Go) :

[  110.445824] sd 2:0:0:0: [sdb] 15130624 512-byte logical blocks: (7.75 GB/7.21 GiB)
[  110.461925]  sdb: sdb1
[  110.468575] sd 2:0:0:0: [sdb] Attached SCSI removable disk

Et maintenant que tu t'es réapproprié ton home, on obtient enfin un message d'erreur spécifique :

[  107.951995] usb 1-5: device descriptor read/64, error -71
[  108.188083] usb 1-5: device descriptor read/64, error -71
[  108.552074] usb 1-5: device descriptor read/64, error -71
[  108.788070] usb 1-5: device descriptor read/64, error -71
[  109.967949] usb 1-5: device not accepting address 8, error -71
[  110.511992] usb 1-5: device not accepting address 9, error -71

Or :

grep -wi 71 /usr/include/asm-generic/errno*.h
/usr/include/asm-generic/errno.h:#define	EPROTO		71	/* Protocol error */

et

zless /usr/share/doc/linux-doc-*/Documentation/usb/error-codes.txt.gz
(...)
-EPROTO (*, **)		a) bitstuff error
 			b) no response packet received within the
			   prescribed bus turn-around time
			c) unknown USB error 


(*) Error codes like -EPROTO, -EILSEQ and -EOVERFLOW normally indicate
hardware problems such as bad devices (including firmware) or cables.

(**) This is also one of several codes that different kinds of host
controller use to indicate a transfer has failed because of device
disconnect.  In the interval before the hub driver starts disconnect
processing, devices may receive such fault reports for every request.

Bon reconnaissons que la description de l'erreur 71 ressemble à un fourre-tout pour toutes les erreurs usb qui ne rentraient pas dans des cases précises...
Mais ici, on retrouve un suspect traditionnel, l'uas :

[  107.118047] usbcore: registered new interface driver uas

Bon, il n'y a plus qu'à désactiver l'uas pour ta clef 13fe:4200

Je vérifie la procédure dans la Doc smartmontools et je reviens.

De ton côté, merci de montrer :

tail -n +7 /etc/fstab

- -

J'ai une connexion pourrie ce matin (même en ligne de commande, j'ai du mal à charger les pages et à répondre) ; n'hésite pas à consulter toi-même la Doc - ou à te faire aider par geole qui connaît bien le sujet de l'uas - si je n'arrive pas à répondre de nouveau.

cedricgfr · Le 16/02/2020, à 18:14

Encore merci pour l'aide.
J'ai fait ça :

tail -n +7 /etc/fstab

Puis je suis aller voir la doc smartmontools
J'ai fait le poin t1.2 installation pour le dépannage d'une clé USB non persistante:

sudo apt-get install --no-install-recommends smartmontools

Puis je suis allé voir le point 3.3 Cas du pilote UAS avec le 3.3.1 pour lister

lsusb -t | grep uas

Mais là il ne passe rien...

cedricgfr · Le 20/02/2020, à 07:19

Je fais remonter. Si quelqu'un a une idée.

moko138 · Le 20/02/2020, à 08:13

Le 16/2, bibi a écrit :

De ton côté, merci de montrer :
tail -n +7 /etc/fstab

Alors ?

= =

D'autre part, montre le retour complet de

lsusb -t | grep -i uas

.

= =

Enfin,
Clef branchée depuis au moins 15 secondes, montre le retour complet de

mkdir -v /tmp/A1 ; echo; sudo mount -v -t auto /dev/disk/by-id/ata-KINGSTON_SA400S37480G_50026B7782F8C3AF-part1  /tmp/A1 ; echo; mkdir -v /tmp/B1 ; echo; sudo mount -v -t auto /dev/disk/by-id/usb-_USB_DISK_2.0_90005AD0E7AFB024-0:0-part1  /tmp/B1 ; echo -e "\n\t= = =\n"; mount -l | grep sd

cedricgfr · Le 20/02/2020, à 13:19

Pour

tail -n +7 /etc/fstab

moi@moi:~$ tail -n +7 /etc/fstab
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=b47c07ac-a2fb-402f-be42-0c2a70bc7920 /               ext4    errors=remount-ro 0       1
/swapfile                                 none            swap    sw              0       0

moi@moi:~$

Pour

lsusb -t | grep -i uas

moi@moi:~$ lsusb -t | grep -i uas
moi@moi:~$

Il ne se passe rien

Pour

mkdir -v /tmp/A1 ; echo; sudo mount -v -t auto /dev/disk/by-id/ata-KINGSTON_SA400S37480G_50026B7782F8C3AF-part1  /tmp/A1 ; echo; mkdir -v /tmp/B1 ; echo; sudo mount -v -t auto /dev/disk/by-id/usb-_USB_DISK_2.0_90005AD0E7AFB024-0:0-part1  /tmp/B1 ; echo -e "\n\t= = =\n"; mount -l | grep sd

voici le retour :

moi@moi:~$ mkdir -v /tmp/A1 ; echo; sudo mount -v -t auto /dev/disk/by-id/ata-KINGSTON_SA400S37480G_50026B7782F8C3AF-part1  /tmp/A1 ; echo; mkdir -v /tmp/B1 ; echo; sudo mount -v -t auto /dev/disk/by-id/usb-_USB_DISK_2.0_90005AD0E7AFB024-0:0-part1  /tmp/B1 ; echo -e "\n\t= = =\n"; mount -l | grep sd
mkdir: création du répertoire '/tmp/A1'

[sudo] Mot de passe de moi : 
mount : /dev/sda1 monté sur /tmp/A1.

mkdir: création du répertoire '/tmp/B1'

mount: /tmp/B1 : bad option; for several filesystems (e.g. nfs, cifs) you might need a /sbin/mount.<type> helper program.

	= = =

/dev/sda1 on / type ext4 (rw,relatime,errors=remount-ro)
cgroup on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
/dev/sda1 on /tmp/A1 type ext4 (rw,relatime,errors=remount-ro)
moi@moi:~$

Merci beaucoup:)

moko138 · Le 20/02/2020, à 15:41

Bon,
Ton fstab ne comporte pas de ligne parasite.

= =

/dev/disk/by-id/ata-KINGSTON_SA400S37480G_50026B7782F8C3AF est ton SSD,
sans rapport (sinon la marque apparente) avec ta clef usb.
Sa première partition est ta racine. Et comme il n'est pas bon de la laisser montée deux fois :
/dev/sda1 on /
et
/dev/sda1 on /tmp/A1
A) tu vas en priorité la démonter du second point de montage ; montre :

sudo umount -v /tmp/A1

= =

Ta clef est donc
/dev/disk/by-id/usb-_USB_DISK_2.0_90005AD0E7AFB024-0:0
et sa partition est
/dev/disk/by-id/usb-_USB_DISK_2.0_90005AD0E7AFB024-0:0-part1

Note l'absence de "Kingston" dans son nom (contrairement à ton ssd). Ce qui corrobore le soupçon de contrefaçon.

La commande de montage

sudo mount -v -t auto /dev/disk/by-id/usb-_USB_DISK_2.0_90005AD0E7AFB024-0:0-part1  /tmp/B1

a renvoyé ce message d'erreur :

mount: /tmp/B1 : bad option; for several filesystems (e.g. nfs, cifs) you might need a /sbin/mount.<type> helper program.

Il est inhabituel, mais il révèle que le système de fichiers ("FS" fat32 ou autre) de la partition n°1 n'est pas reconnu.

Donc
B) Montre la description retournée par

sudo parted -l | grep -A11 90005

.
C) Tu nous diras aussi comment se comporte ta clef avec d'autres systèmes d'exploitation.

cedricgfr · Le 20/02/2020, à 23:20

Pour la A :

moi@moi:~$ sudo umount -v /tmp/A1
[sudo] Mot de passe de moi : 
umount: /tmp/A1 démonté
moi@moi:~$

Pour le B, il ne s'est rien passé :

moi@moi:~$ sudo parted -l | grep -A11 90005
moi@moi:~$

En ce qui concerne mes clés elles fonctionnent toutes bien avec W10
Je précise que j'ai le problème avec toutes les clés . Pas qu'une seule..

moko138 · Le 21/02/2020, à 00:38

Clef branchée depuis au moins 15 secondes, montre

sudo parted -l

cedricgfr · Le 21/02/2020, à 18:37

Désolé pour le retard.
voici le retour

moi@moi:~$ sudo parted -l
[sudo] Mot de passe de moi : 
Modèle : ATA KINGSTON SA400S3 (scsi)
Disque /dev/sda : 480GB
Taille des secteurs (logiques/physiques) : 512B/512B
Table de partitions : msdos
Drapeaux de disque : 

Numéro  Début   Fin    Taille  Type     Système de fichiers  Drapeaux
 1      1049kB  480GB  480GB   primary  ext4                 démarrage


Modèle :  USB DISK 2.0 (scsi)
Disque /dev/sdb : 4009MB
Taille des secteurs (logiques/physiques) : 512B/512B
Table de partitions : msdos
Drapeaux de disque : 

Numéro  Début   Fin     Taille  Type     Système de fichiers  Drapeaux
 1      4129kB  4009MB  4005MB  primary  fat32


moi@moi:

moko138 · Le 21/02/2020, à 20:28

En #18, on voyait une clef de 8 Go :

sd 2:0:0:0: [sdb] 15130624 512-byte logical blocks: (7.75 GB/7.21 GiB)

Là, le système voit un support de 4 Go

Modèle :  USB DISK 2.0 (scsi)
Disque /dev/sdb : 4009MB

Est-ce la même clef qui est vue différemment ? Ou bien as-tu branché un support différent ?

cedricgfr · Le 21/02/2020, à 21:44

J'ai branché une autre clé. Il fallait la même ?

moko138 · Le 22/02/2020, à 07:37

Oui, il vaut mieux continuer avec la clef pour laquelle tu as montré le test de diagnostic, en application de la règle de Claude BERNARD, de ne changer qu'un seul facteur entre deux expériences.

Faute de quoi on risque de passer à côté d'un double problème (cas rencontré en ./viewtopic.php?pid=22124541#p22124541 : un problème-système et un problème spécifique à une clef). Et de ne proposer qu'un seul des deux remèdes nécessaires.

moko138 · Le 22/02/2020, à 10:18

Après relecture de l'ensemble du fil,
il est frappant de voir que par deux fois (en #18 et en #24), quand tu as branché ta clef usb sur le port (= prise) n°3 du bus n°1, s'en sont suivies, dans la demi-seconde, des déconnexions - reconnexions d'un autre périphérique sur le port n°5 du même bus.

Je n'exclus pas un problème matériel concerant le contrôleur usb n°1 (*) sur la carte-mère.
D'où l'intérêt de tester si le problème est bien indépendant de ton système installé.
Donc je renouvelle ma demande du 20/2 :

C) Tu nous diras aussi comment se comporte ta clef avec d'autres systèmes d'exploitation.

Si tu n'as qu'un seul système d'exploitation sur ta machine, il te suffira de démarrer une session live, par exemple à partir de ton support d'installation.

___
(*) Tu as deux bus usb :

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

Dernière modification par moko138 (Le 22/02/2020, à 10:26)

cedricgfr · Le 22/02/2020, à 12:33

moko138 a écrit :

Donc je renouvelle ma demande du 20/2

J'ai répondu en #34. Avec W10, je n'ai aucun problème, quelles que soient les clés.

moko138 · Le 22/02/2020, à 13:51

cedricgfr a écrit :

J'ai répondu en #34. Avec W10, je n'ai aucun problème, quelles que soient les clés.

OK. Je n'avais pas compris que tu parlais de win10 sur la même machine. Ce qui aurait été presque clair si tu avais donné le retour de

sudo fdisk -l

que hibou7 t'avait demandé dès le message #4.

Puisque tu as win10 sur la même machine, lis et applique ceci : ./viewtopic.php?pid=22194449#p22194449

cedricgfr · Le 22/02/2020, à 14:08

Je suis désolé mais je n'avais pas compris qu'il fallait que ce soit nsur la même machine..
Non je disais que mes clés fonctionnent sur w10 mais sur d'autres pc.
Je n'ai que Ubuntu sur ce PC

moko138 · Le 22/02/2020, à 16:13

Si tu n'as qu'un seul système d'exploitation sur ta machine, il te suffira de démarrer une session live, par exemple à partir de ton support d'installation.

...et de voir si les clefs marchent mieux ou pas.

cedricgfr · Le 22/02/2020, à 23:02

Bonsoir à tous,

j'allais passer en session live. Au moment daller dans le bios pour booter sur ma clé, j'ai râté le bios et mon ordinateur a redémarré.
Et là surprise, toutes mes clés fonctionnent ! :rolleyes::rolleyes:

Je ne comprends pas. Pour le moment je ne vais pas mettre en résolu car je n'ai rien fait entre le dernier post et le redémarrage.
J'ai peur que le problème revienne...

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 16/02/2020, à 01:53

Re : not authorized to perform opération

#27 Le 16/02/2020, à 08:51

Re : not authorized to perform opération

#28 Le 16/02/2020, à 10:08

Re : not authorized to perform opération

#29 Le 16/02/2020, à 18:14

Re : not authorized to perform opération

#30 Le 20/02/2020, à 07:19

Re : not authorized to perform opération

#31 Le 20/02/2020, à 08:13

Re : not authorized to perform opération

#32 Le 20/02/2020, à 13:19

Re : not authorized to perform opération

#33 Le 20/02/2020, à 15:41

Re : not authorized to perform opération

#34 Le 20/02/2020, à 23:20

Re : not authorized to perform opération

#35 Le 21/02/2020, à 00:38

Re : not authorized to perform opération

#36 Le 21/02/2020, à 18:37

Re : not authorized to perform opération

#37 Le 21/02/2020, à 20:28

Re : not authorized to perform opération

#38 Le 21/02/2020, à 21:44

Re : not authorized to perform opération

#39 Le 22/02/2020, à 07:37

Re : not authorized to perform opération

#40 Le 22/02/2020, à 10:18

Re : not authorized to perform opération

#41 Le 22/02/2020, à 12:33

Re : not authorized to perform opération

#42 Le 22/02/2020, à 13:51

Re : not authorized to perform opération

#43 Le 22/02/2020, à 14:08

Re : not authorized to perform opération

#44 Le 22/02/2020, à 16:13

Re : not authorized to perform opération

#45 Le 22/02/2020, à 23:02

Re : not authorized to perform opération

Pied de page des forums