1. Forum
  2. Usenet
  3. LINUX.DEBIAN.USER.ITALIAN

  • Stranezza dischi Usb

    From franchi@modula.net@21:1/5 to All on Mon Aug 21 17:10:01 2023
    This is a multi-part message in MIME format.
    Salve a tutti.

    Rilevo questo stranezza quando collego dischi Usb:

    Caso A)
    Sul monitor Vga del server  è presente la videata di login di Gnome e l'operatore, senza fare login, collega un disco esterno Usb formattato Ext4.
    Mi collego al server con Ssh e non vedo alcun disco esterno connesso.
    Ovvero, non lo vedo listato in /dev/disk/by-uuid né in /dev/disk/by-id.

    Caso B)
    Sul monitor Vga del server è presente la videata di login a caratteri e l'operatore, senza fare login, collega lo stesso disco esterno sulla
    stessa porta Usb.
    Mi collego al server con Ssh e vedo che il disco esterno Usb è connesso. Ovvero, lo vedo listato sia in /dev/disk/by-uuid che in /dev/disk/by-id.

    Non ho pieno controllo sul server remoto: mi devo fidare di quello che
    mi dice l'operatore e quindi ci potrebbero essere anche altre cause.

    Qualcuno si è mai imbattuto in qualcosa di simile?

    Luciano



    <html>
    <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    </head>
    <body>
    <font face="Arial">Salve a tutti.<br>
    <br>
    Rilevo questo stranezza quando collego dischi Usb:<br>
    <br>
    Caso A)<br>
    Sul monitor Vga del server  è presente la videata di login di
    Gnome e l'operatore, senza fare login, collega un disco esterno
    Usb formattato Ext4.<br>
    Mi collego al server con Ssh e non vedo alcun disco esterno
    connesso. Ovvero, non lo vedo listato in /dev/disk/by-uuid né in
    /dev/disk/by-id. <br>
    <br>
    Caso B)<br>
    Sul monitor Vga del server è presente la videata di login a
    caratteri e l'operatore, senza fare login, collega lo stesso disco
    esterno sulla stessa porta Usb. <br>
    Mi collego al server con Ssh e vedo che il disco esterno Usb è
    connesso. Ovvero, lo vedo listato sia in /dev/disk/by-uuid che in
    /dev/disk/by-id.<br>
    <br>
    Non ho pieno controllo sul server remoto: mi devo fidare di quello
    che mi dice l'operatore e quindi ci potrebbero essere anche altre
    cause.<br>
    <br>
    Qualcuno si è mai imbattuto in qualcosa di simile?<br>
    <br>
    Luciano<br>
    <br>
     <br>
      <br>
    </font>
    </body>
    </html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paolo Redaelli@21:1/5 to All on Tue Aug 22 21:50:01 2023
    This is a multi-part message in MIME format.
    Vien da chiedersi se nel caso A i moduli del kernel addetti alla
    gestione dell'USB siano caricati...  usb_storage e scsi_mod son caricati?

    Nei log deve "per forza" esserci qualcosa nei due casi....

    Il 21/08/23 16:59, franchi@modula.net ha scritto:
    Salve a tutti.

    Rilevo questo stranezza quando collego dischi Usb:

    Caso A)
    Sul monitor Vga del server  è presente la videata di login di Gnome e l'operatore, senza fare login, collega un disco esterno Usb formattato
    Ext4.
    Mi collego al server con Ssh e non vedo alcun disco esterno connesso.
    Ovvero, non lo vedo listato in /dev/disk/by-uuid né in /dev/disk/by-id.

    Caso B)
    Sul monitor Vga del server è presente la videata di login a caratteri
    e l'operatore, senza fare login, collega lo stesso disco esterno sulla
    stessa porta Usb.
    Mi collego al server con Ssh e vedo che il disco esterno Usb è
    connesso. Ovvero, lo vedo listato sia in /dev/disk/by-uuid che in /dev/disk/by-id.

    Non ho pieno controllo sul server remoto: mi devo fidare di quello che
    mi dice l'operatore e quindi ci potrebbero essere anche altre cause.

    Qualcuno si è mai imbattuto in qualcosa di simile?

    Luciano



    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    </head>
    <body>
    <p>Vien da chiedersi se nel caso A i moduli del kernel addetti alla
    gestione dell'USB siano caricati...  usb_storage e scsi_mod son
    caricati? <br>
    </p>
    <p>Nei log deve "per forza" esserci qualcosa nei due casi.... <br>
    </p>
    <div class="moz-cite-prefix">Il 21/08/23 16:59, <a class="moz-txt-link-abbreviated" href="mailto:franchi@modula.net">franchi@modula.net</a>
    ha scritto:<br>
    </div>
    <blockquote type="cite"
    cite="mid:ab691563-9c55-5f98-0b60-30bbfe07d10e@modula.net">
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    <font face="Arial">Salve a tutti.<br>
    <br>
    Rilevo questo stranezza quando collego dischi Usb:<br>
    <br>
    Caso A)<br>
    Sul monitor Vga del server  è presente la videata di login di
    Gnome e l'operatore, senza fare login, collega un disco esterno
    Usb formattato Ext4.<br>
    Mi collego al server con Ssh e non vedo alcun disco esterno
    connesso. Ovvero, non lo vedo listato in /dev/disk/by-uuid né in
    /dev/disk/by-id. <br>
    <br>
    Caso B)<br>
    Sul monitor Vga del server è presente la videata di login a
    caratteri e l'operatore, senza fare login, collega lo stesso
    disco esterno sulla stessa porta Usb. <br>
    Mi collego al server con Ssh e vedo che il disco esterno Usb è
    connesso. Ovvero, lo vedo listato sia in /dev/disk/by-uuid che
    in /dev/disk/by-id.<br>
    <br>
    Non ho pieno controllo sul server remoto: mi devo fidare di
    quello che mi dice l'operatore e quindi ci potrebbero essere
    anche altre cause.<br>
    <br>
    Qualcuno si è mai imbattuto in qualcosa di simile?<br>
    <br>
    Luciano<br>
    <br>
     <br>
      <br>
    </font> </blockquote>
    </body>
    </html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From franchi@modula.net@21:1/5 to All on Wed Aug 23 01:40:01 2023
    This is a multi-part message in MIME format.
    Il 22/08/2023 21:44, Paolo Redaelli ha scritto:

    Vien da chiedersi se nel caso A i moduli del kernel addetti alla
    gestione dell'USB siano caricati...  usb_storage e scsi_mod son caricati?

    Nei log deve "per forza" esserci qualcosa nei due casi....

    Si deve esserci qualcosa per forza. Appena posso accedere nuovamente al
    server controllo e riferisco.
    L.

    Il 21/08/23 16:59, franchi@modula.net ha scritto:
    Salve a tutti.

    Rilevo questo stranezza quando collego dischi Usb:

    Caso A)
    Sul monitor Vga del server  è presente la videata di login di Gnome e
    l'operatore, senza fare login, collega un disco esterno Usb
    formattato Ext4.
    Mi collego al server con Ssh e non vedo alcun disco esterno connesso.
    Ovvero, non lo vedo listato in /dev/disk/by-uuid né in /dev/disk/by-id.

    Caso B)
    Sul monitor Vga del server è presente la videata di login a caratteri
    e l'operatore, senza fare login, collega lo stesso disco esterno
    sulla stessa porta Usb.
    Mi collego al server con Ssh e vedo che il disco esterno Usb è
    connesso. Ovvero, lo vedo listato sia in /dev/disk/by-uuid che in
    /dev/disk/by-id.

    Non ho pieno controllo sul server remoto: mi devo fidare di quello
    che mi dice l'operatore e quindi ci potrebbero essere anche altre cause.

    Qualcuno si è mai imbattuto in qualcosa di simile?

    Luciano




    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    </head>
    <body>
    <br>
    <br>
    <div class="moz-cite-prefix">Il 22/08/2023 21:44, Paolo Redaelli ha
    scritto:<br>
    </div>
    <blockquote type="cite"
    cite="mid:58b9f24e-9887-24e6-0e8a-380236b1f6c0@gmail.com">
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <p>Vien da chiedersi se nel caso A i moduli del kernel addetti
    alla gestione dell'USB siano caricati...  usb_storage e scsi_mod
    son caricati? <br>
    </p>
    <p>Nei log deve "per forza" esserci qualcosa nei due casi.... <br>
    </p>
    </blockquote>
    Si deve esserci qualcosa per forza. Appena posso accedere nuovamente
    al server controllo e riferisco.<br>
    L. <br>
    <blockquote type="cite"
    cite="mid:58b9f24e-9887-24e6-0e8a-380236b1f6c0@gmail.com">
    <p> </p>
    <div class="moz-cite-prefix">Il 21/08/23 16:59, <a
    class="moz-txt-link-abbreviated moz-txt-link-freetext"
    href="mailto:franchi@modula.net" moz-do-not-send="true">franchi@modula.net</a>
    ha scritto:<br>
    </div>
    <blockquote type="cite"
    cite="mid:ab691563-9c55-5f98-0b60-30bbfe07d10e@modula.net">
    <meta http-equiv="content-type" content="text/html;
    charset=UTF-8">
    <font face="Arial">Salve a tutti.<br>
    <br>
    Rilevo questo stranezza quando collego dischi Usb:<br>
    <br>
    Caso A)<br>
    Sul monitor Vga del server  è presente la videata di login di
    Gnome e l'operatore, senza fare login, collega un disco
    esterno Usb formattato Ext4.<br>
    Mi collego al server con Ssh e non vedo alcun disco esterno
    connesso. Ovvero, non lo vedo listato in /dev/disk/by-uuid né
    in /dev/disk/by-id. <br>
    <br>
    Caso B)<br>
    Sul monitor Vga del server è presente la videata di login a
    caratteri e l'operatore, senza fare login, collega lo stesso
    disco esterno sulla stessa porta Usb. <br>
    Mi collego al server con Ssh e vedo che il disco esterno Usb è
    connesso. Ovvero, lo vedo listato sia in /dev/disk/by-uuid che
    in /dev/disk/by-id.<br>
    <br>
    Non ho pieno controllo sul server remoto: mi devo fidare di
    quello che mi dice l'operatore e quindi ci potrebbero essere
    anche altre cause.<br>
    <br>
    Qualcuno si è mai imbattuto in qualcosa di simile?<br>
    <br>
    Luciano<br>
    <br>
     <br>
      <br>
    </font> </blockquote>
    </blockquote>
    <br>
    </body>
    </html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From franchi@modula.net@21:1/5 to All on Wed Aug 23 01:50:01 2023
    Il 22/08/2023 10:12, Leonardo Boselli ha scritto:
    posso solo fare una ipotesi: che gnome una volta partito riservi i
    dischi esterni all'utente sulla machcina locale, e li attivi solo una
    volta che il login locale viene fatto.
    Non lo vedo illogico

    L'ho pensato anch'io ma mi sembra strano che semplicemente premendo F1 o
    F2, senza aver effettuato alcun login, il server si comporti diversamente. Comunque finché non rientra l'operatore dalle ferie non posso accedere.
    L.
    On Tue, 22 Aug 2023, franchi@modula.net wrote:

    Il 21/08/2023 17:12, Leonardo Boselli ha scritto:
          Lo schermo di login dovrebbe essere sempre lo stesso, a amno che >>       non cambi lo schermo virtuale.
          hai guardato /var/log/syslog che dice quanbdo attacchi il disco >>       ?

    Si, è sempre lo stesso, ed è Gnome.

    Se arresto Gnome e dopo faccio collegare il disco Usb il
    riconoscimento è
    immediato.

    Appena rientra l'operatore dalle ferie faccio controlli più
    approfonditi su
    syslog.

    L.
          On Mon, 21 Aug 2023, franchi@modula.net wrote:

                Salve a tutti.

                Rilevo questo stranezza quando collego dischi Usb:

                Caso A)
                Sul monitor Vga del server  è presente la videata di
                login di Gnome e
                l'operatore, senza fare login, collega un disco
                esterno Usb formattato Ext4.
                Mi collego al server con Ssh e non vedo alcun disco >>             esterno connesso.
                Ovvero, non lo vedo listato in /dev/disk/by-uuid né >>             in /dev/disk/by-id.

                Caso B)
                Sul monitor Vga del server è presente la videata di >>             login a caratteri e
                l'operatore, senza fare login, collega lo stesso
                disco esterno sulla stessa
                porta Usb.
                Mi collego al server con Ssh e vedo che il disco
                esterno Usb è connesso.
                Ovvero, lo vedo listato sia in /dev/disk/by-uuid che >>             in /dev/disk/by-id.

                Non ho pieno controllo sul server remoto: mi devo
                fidare di quello che mi
                dice l'operatore e quindi ci potrebbero essere anche >>             altre cause.

                Qualcuno si è mai imbattuto in qualcosa di simile? >>
                Luciano






          --
          Leonardo Boselli
          Firenze, Toscana, Europa
          http://i.trail.it
          tel:+393287329225





    --
    Leonardo Boselli
    Firenze, Toscana, Europa
    http://i.trail.it
    tel:+393287329225

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Piviul@21:1/5 to franchi@modula.net on Wed Aug 23 08:10:01 2023
    On 8/23/23 01:39, franchi@modula.net wrote:


    Il 22/08/2023 10:12, Leonardo Boselli ha scritto:
    posso solo fare una ipotesi: che gnome una volta partito riservi i
    dischi esterni all'utente sulla machcina locale, e li attivi solo una
    volta che il login locale viene fatto.
    Non lo vedo illogico

    L'ho pensato anch'io ma mi sembra strano che semplicemente premendo F1
    o F2, senza aver effettuato alcun login, il server si comporti
    diversamente.
    Comunque finché non rientra l'operatore dalle ferie non posso accedere.

    scusa ma cosa c'entrano F1 e F2?

    Piviul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From franchi@modula.net@21:1/5 to All on Wed Aug 23 09:50:01 2023
    Il 23/08/2023 08:03, Piviul ha scritto:

    On 8/23/23 01:39, franchi@modula.net wrote:


    Il 22/08/2023 10:12, Leonardo Boselli ha scritto:
    posso solo fare una ipotesi: che gnome una volta partito riservi i
    dischi esterni all'utente sulla machcina locale, e li attivi solo
    una volta che il login locale viene fatto.
    Non lo vedo illogico

    L'ho pensato anch'io ma mi sembra strano che semplicemente premendo
    F1 o F2, senza aver effettuato alcun login, il server si comporti
    diversamente.
    Comunque finché non rientra l'operatore dalle ferie non posso accedere.

    scusa ma cosa c'entrano F1 e F2?

    Dalla console del server si passa dall'interfaccia a caratteri a quella
    grafica di Gnome
    L.
    Piviul



    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paolo Redaelli@21:1/5 to All on Wed Aug 23 19:20:01 2023
    Il 23 agosto 2023 09:41:56 CEST, "franchi@modula.net" <franchi@modula.net> ha scritto:


    scusa ma cosa c'entrano F1 e F2?

    Dalla console del server si passa dall'interfaccia a caratteri a quella grafica di Gnome

    Che a dirla proprio tutta mi sembra sia Alt-F1, alt-F2 eccetera 🤪

    --
    Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marco Gaiarin@21:1/5 to All on Wed Aug 23 22:20:01 2023
    Mandi! franchi@modula.net
    In chel di` si favelave...

    Qualcuno si mai imbattuto in qualcosa di simile?

    L'utente in questione fa parte dei gruppi necessari alla gestione delle chiavette, 'pugdev' mi pare a memoria?

    --
    Il Re di Spagna fece vela, verso l'isola incantata
    pero` quell'isola non c'era,
    e mai nessuno l'ha trovata (F. Guccini)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Beppe Cantanna@21:1/5 to All on Thu Aug 24 17:40:01 2023
    Per replicare un po' la stessa condizione descritta procedo così:

    In pc acceso fermo sulla schermata di login di Debian, inserisco una
    chiavetta usb e mi collego in ssh.

    Il disco non risulta in mount automatico.

    $ df -h
    Filesystem Size Used Avail Use% Mounted on
    udev 1,5G 0 1,5G 0% /dev
    tmpfs 299M 1,4M 298M 1% /run
    /dev/sda5 46G 25G 19G 58% /
    tmpfs 1,5G 0 1,5G 0% /dev/shm
    tmpfs 5,0M 8,0K 5,0M 1% /run/lock
    tmpfs 299M 88K 299M 1% /run/user/106
    tmpfs 299M 84K 299M 1% /run/user/1000

    pur essendo visto come dispositivo usb e pur essendo gestibile da fdisk:

    Bus 003 Device 003: ID 04f2:b159 Chicony Electronics Co., Ltd CNF8243 Webcam *Bus 003 Device 002: ID 13fe:3d23 Phison Electronics Corp. USB DISK Pro*
    Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
    Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
    Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
    Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

    bpxroot@debianq:~$ sudo fdisk -l | grep ^Disk\ /dev/sd
    [sudo] password for bpxroot:
    Disk /dev/sda: 298,09 GiB, 320072933376 bytes, 625142448 sectors
    Disk /dev/sdb: 7,46 GiB, 8006926336 bytes, 15638528 sectors

    inoltre è anche visibile in /dev/disk/by-uuid

    bpxroot@debianq:~$ ls -la /dev/disk/by-uuid/
    total 0
    drwxr-xr-x 2 root root 200 ago 24 2023 .
    drwxr-xr-x 7 root root 140 ago 24 2023 ..
    lrwxrwxrwx 1 root root 10 ago 24 2023
    0177e8bc-8764-49b1-816e-88eef7b24a8b -> ../../sda7
    *lrwxrwxrwx 1 root root 10 ago 24 2023 36E0-356D -> ../../sdb1*
    lrwxrwxrwx 1 root root 10 ago 24 2023
    49386f18-8d88-4c37-8218-00e332596116 -> ../../sda4
    lrwxrwxrwx 1 root root 10 ago 24 2023 6EFF820F3CDADEE2 -> ../../sda8 lrwxrwxrwx 1 root root 10 ago 24 2023 84A0AA21A0AA1A26 -> ../../sda2 lrwxrwxrwx 1 root root 10 ago 24 2023
    9ec87039-6e11-4ab1-bc36-1d97bf8dddc7 -> ../../sda5
    lrwxrwxrwx 1 root root 10 ago 24 2023
    aa012360-3155-4154-9671-e72112392d5d -> ../../sda6
    lrwxrwxrwx 1 root root 10 ago 24 2023 AE42C65642C622C7 -> ../../sda1


    però volgio partire da una condizione più svantaggiata e faccio un eject in questo modo non viene più visto né da fdisk né in /dev/disk/by-uuid:

    bpxroot@debianq:~$ eject /dev/sdb
    bpxroot@debianq:~$

    bpxroot@debianq:~$ sudo fdisk -l | grep ^Disk\ /dev/sd
    Disk /dev/sda: 298,09 GiB, 320072933376 bytes, 625142448 sectors

    bpxroot@debianq:~$ ls -la /dev/disk/by-uuid/ | grep sdb
    bpxroot@debianq:~$

    ma il bus usb continua a vederlo:

    bpxroot@debianq:~$ lsusb
    Bus 003 Device 003: ID 04f2:b159 Chicony Electronics Co., Ltd CNF8243 Webcam Bus 003 Device 002: ID 13fe:3d23 Phison Electronics Corp. USB DISK Pro
    Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
    Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
    Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
    Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub


    adesso però voglio usare la chiavetta sempre da una connessione ssh, quindi
    do il comando eject con l'opzione -t e il disco usb torna a essere visibile
    sia in /dev/disk/by-uuid

    bpxroot@debianq:~$ eject -t /dev/sdb
    bpxroot@debianq:~$
    bpxroot@debianq:~$ sudo fdisk -l | grep ^Disk\ /dev/sd
    Disk /dev/sda: 298,09 GiB, 320072933376 bytes, 625142448 sectors
    Disk /dev/sdb: 7,46 GiB, 8006926336 bytes, 15638528 sectors
    bpxroot@debianq:~$
    bpxroot@debianq:~$ ls -la /dev/disk/by-uuid/ | grep sdb
    lrwxrwxrwx 1 root root 10 ago 24 16:24 36E0-356D -> ../../sdb1


    ma continua a non essere in mount:

    bpxroot@debianq:~$ df -h
    Filesystem Size Used Avail Use% Mounted on
    udev 1,5G 0 1,5G 0% /dev
    tmpfs 299M 1,4M 298M 1% /run
    /dev/sda5 46G 25G 19G 58% /
    tmpfs 1,5G 0 1,5G 0% /dev/shm
    tmpfs 5,0M 8,0K 5,0M 1% /run/lock
    tmpfs 299M 88K 299M 1% /run/user/106
    tmpfs 299M 84K 299M 1% /run/user/1000


    Allora provo a attivare il mount con udiskctl, ma mi chiede
    l'autenticazione come root. Il problema è che se mi autentifico poi il
    mount lo fa come utente root e non è questo che voglio.

    $ udisksctl mount -b /dev/disk/by-label/MULTIBOOT
    ==== AUTHENTICATING FOR org.freedesktop.udisks2.filesystem-mount-other-seat ====
    Authentication is required to mount USB DISK Pro (/dev/sdb1)
    Authenticating as: root
    Password:

    allora, dato che le credenziale mi vengono chieste per questa azione:

    org.freedesktop.udisks2.filesystem-mount-other-seat


    Regolata dalle impostazioni presenti in questo file:

    /usr/share/polkit-1/actions/org.freedesktop.UDisks2.policy

    modifico il suo default in questo modo:

    impostazione originale:

    <!-- mount a device attached to another seat -->
    <action id="org.freedesktop.udisks2.filesystem-mount-other-seat">
    <description>Mount a filesystem from a device plugged into another seat</description>
    <description xml:lang="zh_TW">掛載插入其他置的裝置的檔案系統</description>
    ...
    <defaults>
    <allow_any>auth_admin</allow_any>
    <allow_inactive>auth_admin</allow_inactive>
    <allow_active>auth_admin_keep</allow_active>
    </defaults>
    </action>


    nuova configurazione:

    <!-- mount a device attached to another seat -->
    <action id="org.freedesktop.udisks2.filesystem-mount-other-seat">
    <description>Mount a filesystem from a device plugged into another seat</description>
    <description xml:lang="zh_TW">掛載插入其他置的裝置的檔案系統</description>
    ...
    <defaults>
    <allow_any>yes</allow_any>
    <allow_inactive>yes</allow_inactive>
    <allow_active>yes</allow_active>
    </defaults>
    </action>


    A questo punto, senza riavviare alcun servizio il mount funziona con
    l'utenza corrente:

    $ udisksctl mount -b /dev/disk/by-label/MULTIBOOT

    *Mounted /dev/sdb1 at /media/bpxroot/MULTIBOOT*

    $ df -h
    Filesystem Size Used Avail Use% Mounted on
    udev 1,5G 0 1,5G 0% /dev
    tmpfs 299M 1,4M 298M 1% /run
    /dev/sda5 46G 25G 19G 58% /
    tmpfs 1,5G 0 1,5G 0% /dev/shm
    tmpfs 5,0M 8,0K 5,0M 1% /run/lock
    tmpfs 299M 88K 299M 1% /run/user/106
    tmpfs 299M 84K 299M 1% /run/user/1000
    */dev/sdb1 7,5G 1,7G 5,9G 22% /media/bpxroot/MULTIBOOT*


    $ ls -la /media/bpxroot/MULTIBOOT
    total 52
    drwxr-xr-x 4 bpxroot bpxroot 4096 gen 1 1970 .
    drwxr-xr-x 3 root root 4096 ago 24 17:29 ..
    drwxr-xr-x 7 bpxroot bpxroot 4096 dic 28 2016 multiboot
    -rw-r--r-- 1 bpxroot bpxroot 33982 ago 30 2019 'Nuovo file'
    drwxr-xr-x 2 bpxroot bpxroot 4096 dic 28 2016 'System Volume Information'


    Il giorno mer 23 ago 2023 alle ore 22:10 Marco Gaiarin < gaio@lilliput.linux.it> ha scritto:

    Mandi! franchi@modula.net
    In chel di` si favelave...

    Qualcuno si è mai imbattuto in qualcosa di simile?

    L'utente in questione fa parte dei gruppi necessari alla gestione delle chiavette, 'pugdev' mi pare a memoria?

    --
    Il Re di Spagna fece vela, verso l'isola incantata
    pero` quell'isola non c'era,
    e mai nessuno l'ha trovata (F. Guccini)




    --
    *CANTANNA Giuseppe*
    cel. +39 349 1998700
    giuseppe.cantanna@glugto.org
    cantanna@glugto.org
    cantanna@gmail.com

    bproot.bc - Linux user n. 502620 registered on http://counter.li.org/
    *Nodo NINUX: *broot*.*


    *Per favore non inviatemi allegati in formato MS
    Office.Utilizzate alternativamente documenti in formato OpenDocument.* http://en.wikipedia.org/wiki/OpenDocument http://it.wikipedia.org/wiki/OpenDocument


    http://www.documentfoundation.org/
    https://it.libreoffice.org/

    <div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace">Per replicare un po&#39; la stessa condizione descritta procedo così:</div><div class="gmail_default" style="font-family:courier new,monospace"><br></div><
    div class="gmail_default" style="font-family:courier new,monospace">In  pc acceso fermo sulla schermata di login di Debian, inserisco una chiavetta usb e mi collego in ssh.</div><div class="gmail_default" style="font-family:courier new,monospace"><br></
    <div c
  • From Paolo Redaelli@21:1/5 to All on Thu Aug 24 19:40:02 2023
    ------30EAQ9HHY23FODMQOFSWOTY14VBJLH
    Content-Type: text/plain;
    charset=utf-8
    Content-Transfer-Encoding: quoted-printable

    Se fai eject non lo vedrai mai. In alcuni casi la periferica viene anche disalimentata.
    Devi fare un umount semplice.
    Dopo un eject l'unico modo per rivedere la periferica è scollegarla e ricollegarla fisicamente
    --
    Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità. ------30EAQ9HHY23FODMQOFSWOTY14VBJLH
    Content-Type: text/html;
    charset=utf-8
    Content-Transfer-Encoding: quoted-printable

    <!DOCTYPE html><html><body><div dir="auto">Se fai eject non lo vedrai mai. In alcuni casi la periferica viene anche disalimentata.<br>Devi fare un umount semplice.<br>Dopo un eject l'unico modo per rivedere la periferica è scollegarla e ricollegarla
    fisicamente</div><div dir="auto"><div class='k9mail-signature'>-- <br>Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.</div></div></body></html>
    ------30EAQ9HHY23FODMQOFSWOTY14VBJLH--

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Beppe Cantanna@21:1/5 to All on Thu Aug 24 23:50:01 2023
    Ciao,
    non cosa fa il tuo pc, d'altronde ho scritto cosa faccio io, non cosa
    succede sul tuo pc e sono anche sicuro che tu prima di fare un'affermazione tanto netta come un anatema tipo "*Se fai eject non lo vedrai mai*"
    sicuramente l'hai verificata. Sui tuoi pc.

    Però quello che ho riportato nella precedente mail non è frutto di ipotesi
    ma è il risultato di comandi dati e output riportato così come è uscito.

    E ti dico che sia sul mio HP ProBook 450 G4, sia sul Compaq 610, entrambi
    con Debian trixie, se hai una chiavetta usb con queste caratteristiche "ID 0951:1624 Kingston Technology DataTraveler G2" vista come /dev/*sdX* dove X
    è la lettera identificativa del device a blocchi, in questo caso /dev/sdc
    e dai il comando "eject /dev/sdc" il device non viene più visto, pur
    essendo ancora elencato da lsusb, ma comunque successivamente puoi riagganciarlo dando il comando *eject -t /dev/sdc*.

    Riporto nuovamente il test.

    Elenco dei dispositivi visti sul bus usb:

    :~$ lsusb
    Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
    Bus 001 Device 004: ID 8087:0a2a Intel Corp. Bluetooth wireless interface
    Bus 001 Device 003: ID 04f2:b595 Chicony Electronics Co., Ltd HP HD Camera
    *Bus 001 Device 007: ID 0951:1624 Kingston Technology DataTraveler G2*
    Bus 001 Device 002: ID 03f0:134a HP, Inc Optical Mouse
    Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


    Qui il disco */dev/sdc* si vede:

    :~$ fdisk -l | grep ^Disk\ /dev/sd
    Disk /dev/sda: 465,76 GiB, 500107862016 bytes, 976773168 sectors
    Disk /dev/sdb: 465,76 GiB, 500107862016 bytes, 976773168 sectors
    *Disk /dev/sdc: 3,73 GiB, 4008706048 bytes, 7829504 sectors*


    eseguo il comando eject /dev/sdc:

    :~$ eject /dev/sdc
    :~$


    e il disco /dev/sdc non si vede più:

    :~$ fdisk -l | grep ^Disk\ /dev/sd | grep sdc
    :~$


    ma il bus usb vede ancora il dispositivo:

    :~$ lsusb
    Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
    Bus 001 Device 004: ID 8087:0a2a Intel Corp. Bluetooth wireless interface
    Bus 001 Device 003: ID 04f2:b595 Chicony Electronics Co., Ltd HP HD Camera
    Bus 001 Device 007: *ID 0951:1624 Kingston Technology DataTraveler G2*
    Bus 001 Device 002: ID 03f0:134a HP, Inc Optical Mouse
    Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


    A questo punto se voglio riagganciarlo vedo che posso fare così:

    :~$ eject -t /dev/sdc
    :~$


    e funziona, succede proprio quello che ho scritto, il disco torna visibile:

    :~$ fdisk -l | grep ^Disk\ /dev/sd | grep sdc
    Disk /dev/sdc: 3,73 GiB, 4008706048 bytes, 7829504 sectors


    Fenomeno che poco si sposa con la tua frase "*Se fai eject non lo vedrai
    mai*". E invece si vede di nuovo.Succede sempre. Su due pc diversi con due dischi usb diversi. Magari sui grandi numeri può anche succedere che "non
    si vedrà mai" ma al momento la mia esperienza dice che si vede.

    Come avrai osservato questi comandi sono stati dati senza l'utilizzo del
    sudo, come se operassi da ambiente grafico pur essendo su un terminale in
    ssh.

    Secondo me è abbastanza interessante saperlo perché può capitare che magari da una sessione vnc per sbaglio sganci il disco usb e poi non sai come riagganciarlo senza andare direttamente in loco.

    Inoltre come è noto, il comando umount, che oltretutto richiede un profilo amministrativo, semplicemente sgancia il dispositivo dal mount point sul filesystem, senza variare minimamente la possibilità di gestirlo con il
    tool fdisk. In altre parole, se fai umount continui a vedere ancora
    /dev/sdc.

    umount e eject, anche se forse non sembra fanno cose diverse.

    Quindi, so che devo fare così se voglio rimuovere il disco dall'elenco dei device /dev/sdX, almeno sui miei pc. Sui tuoi non lo so.

    E dato che a me funziona, ho pensato di condividere la cosa, che poi non è tanto strana, infatti se guardiamo il relativo help di ject vediamo:

    ~$ eject -h | grep ^\ -t
    -t, --trayclose close tray

    Che evidentemente riferito a un lettore ottico vuol dire che prova a
    chiudere il cassettino, mentre applicato a un dispositivo a blocchi come
    una chiavetta usb evidentemente corrisponderà a riattivarlo. Ti confesso
    che non ho letto il sorgente di eject, ma ho visto che qui funziona così.
    Tra l'altro questa chiavetta avrà almeno 10 anni e non credo implementi tecnologie sperimentali.

    Ma comunque la mia mail voleva dare un contributo nel rispondere alla
    domanda iniziale fatta da franchi@modula.net, in quanto mettendomi in una condizione simile al suo *caso A)* ho potuto far comparire il device in /dev/disk/by-uuid senza che nessuno facesse il login nell'ambiente grafico, ricadendo quindi nella situazione simile al *caso B)*, ottenendo il
    controllo del disco usb e il mount automatico da ssh variando le
    impostazioni del file /usr/share/polkit-1/actions/org.freedesktop.UDisks2.policy senza che
    nessuno accedesse sul DE con una sessione locale.

    L'unico dubbio che mi resta è relativo al device da puntare con il comando ejec -t /dev/sdX, ma probabilmente dmesg potrebbe dare indizi in merito.


    Ciao


    Il giorno gio 24 ago 2023 alle ore 19:38 Paolo Redaelli < paolo.redaelli@gmail.com> ha scritto:

    Se fai eject non lo vedrai mai. In alcuni casi la periferica viene anche disalimentata.
    Devi fare un umount semplice.
    Dopo un eject l'unico modo per rivedere la periferica è scollegarla e ricollegarla fisicamente
    --
    Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.



    --
    *CANTANNA Giuseppe*
    cel. +39 349 1998700
    giuseppe.cantanna@glugto.org
    cantanna@glugto.org
    cantanna@gmail.com

    bproot.bc - Linux user n. 502620 registered on http://counter.li.org/
    *Nodo NINUX: *broot*.*


    *Per favore non inviatemi allegati in formato MS
    Office.​​Utilizza​te​ alternativamente documenti in formato OpenDocument.*
    ​
    http://en.wikipedia.org/wiki/OpenDocument <http://en.wikipedia.org/wiki/OpenDocument>
    ​ ​
    http://it.wikipedia.org/wiki/OpenDocument


    *​*http://www.documentfoundation.org/
    * ​ *https://it.libreoffice.org/
    ​ ​

    <div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace">Ciao,</div><div class="gmail_default" style="font-family:courier new,monospace">non cosa fa il tuo pc, d&#39;altronde ho scritto cosa faccio io, non cosa succede sul tuo
    pc e sono anche sicuro che tu prima di fare un&#39;affermazione tanto netta come un anatema tipo &quot;<i>Se fai eject non lo vedrai mai</i>&quot; sicuramente l&#39;hai verifica
  • From Davide Prina@21:1/5 to All on Tue Aug 29 23:50:01 2023
    Beppe Cantanna ha scritto:

    Paolo Redaelli ha scritto:

    Se fai eject non lo vedrai mai. In alcuni casi la periferica viene
    anche disalimentata.

    in effetti eject -t potrebbe non funzionare
    $ man eject
    [...]
    -t, --trayclose
    With this option the drive is given a CD-ROM tray close
    command. Not all devices support this command.
    [...]


    dai il comando "eject /dev/sdc" il device non viene più visto,
    pur essendo ancora elencato da lsusb, ma comunque successivamente
    puoi riagganciarlo dando il comando eject -t /dev/sdc.

    interessante, anche interessanti le prove che hai fatto con il
    login.

    Però, secondo me, il disco USB non dovrebbe essere caricato prima
    del login dell'utente. Se si collega qualcuno in SSH dovrebbe essere
    lui a compiere l'operazione, se ne ha i permessi.
     
    il comando umount, che oltretutto richiede un profilo amministrativo,

    non è detto, se non erro attualmente l'utente principale non
    amministratore ha il privilegio per fare il mount/unmount
    Se non erro dovrebbe essere installato il pacchetto pmount che permette
    proprio di fare questa operazione

    Aggiungo un'altra informazione interessante.
    Visto che ora c'è systemd si possono usare anche i comandi:

    per smontare il disco:
    $ udisksctl unmount -b /dev/sdc1

    per togliergli l'alimentazione
    $ udisksctl power-off -b /dev/sdc

    Poi non so se sia possibile rifornire l'alimentazione o bisogni
    toglierlo e rimettere la penna USB.

    Ciao
    Davide

    --
    La mia privacy non è affar tuo
    https://noyb.eu/it
    - You do not have my permission to use this email to train an AI -
    If you use this to train your AI than you accept to distribuite under AGPL license >= 3.0 all the model trained, all the source you have used to
    training your model and all the source of the program that use that model

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Beppe Cantanna@21:1/5 to All on Wed Aug 30 05:30:01 2023
    Se fai eject non lo vedrai mai. In alcuni casi la periferica viene
    anche disalimentata.

    in effetti eject -t potrebbe non funzionare
    $ man eject
    [...]
    -t, --trayclose
    With this option the drive is given a CD-ROM tray close
    command. Not all devices support this command.
    [...]

    Sì ho letto anche la parte "Not all devices support this command" che
    comunque è inerente al ripristiono del device.
    In ogni caso è una strada che si può ipotizzare di seguire considerando che su due USB vecchiotti funziona.

    Certo non ho statistiche sviluppate su vasta scala.



    dai il comando "eject /dev/sdc" il device non viene più visto,
    pur essendo ancora elencato da lsusb, ma comunque successivamente
    puoi riagganciarlo dando il comando eject -t /dev/sdc.

    interessante, anche interessanti le prove che hai fatto con il
    login.

    Però, secondo me, il disco USB non dovrebbe essere caricato prima
    del login dell'utente. Se si collega qualcuno in SSH dovrebbe essere
    lui a compiere l'operazione, se ne ha i permessi.

    Sicuramente è una situazione spuria. Però se sei in remoto non è detto che hai modo di raggiungere fisicamente il sistema.
    Poi evidentemente si tratta di casi specifici. Anche se hai attivato vnc e
    puoi fare il login grafico, magari hai dei dischi usb a cui vuoi accedere e
    se non sbaglio questo mount viene fatto su un path di proprietà dell'utente.

    il comando umount, che oltretutto richiede un profilo amministrativo,

    non è detto, se non erro attualmente l'utente principale non
    amministratore ha il privilegio per fare il mount/unmount
    Se non erro dovrebbe essere installato il pacchetto pmount che permette
    proprio di fare questa operazione

    La cosa figa del comando "eject -t" è che se funziona, lavora come quando inseerisci il disco e ti viene fatto il mount automatico, senza dovergli specificare il punto di mount e altre cose che decide il sistema.

    Per esempio, qui si vede che viene messo nel path /media dell'utente.

    bpxroot@hpebian:~$ findmnt /dev/sdc1
    TARGET SOURCE FSTYPE OPTIONS
    /media/bpxroot/CCCOMA_X64F /dev/sdc1 vfat rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro



    Aggiungo un'altra informazione interessante.
    Visto che ora c'è systemd si possono usare anche i comandi:

    per smontare il disco:
    $ udisksctl unmount -b /dev/sdc1

    per togliergli l'alimentazione
    $ udisksctl power-off -b /dev/sdc

    Poi non so se sia possibile rifornire l'alimentazione o bisogni
    toglierlo e rimettere la penna USB.


    Ho provato anche con udisksctl ma c'è qualcosa che non gli piace :( anche
    con sudo.


    bpxroot@hpebian:~$ /usr/bin/udisksctl unmount -b /dev/sdc
    Object /org/freedesktop/UDisks2/block_devices/sdc is not a mountable filesystem.

    bpxroot@hpebian:~$ sudo /usr/bin/udisksctl unmount -b /dev/sdc
    [sudo] password for bpxroot:
    Object /org/freedesktop/UDisks2/block_devices/sdc is not a mountable filesystem.

    bpxroot@hpebian:~$ sudo /usr/bin/udisksctl power-off -b /dev/sdc
    Error powering off drive: The drive in use: Device /dev/sdc1 is mounted (udisks-error-quark, 14)

    bpxroot@hpebian:~$ /usr/bin/udisksctl power-off -b /dev/sdc
    Error powering off drive: The drive in use: Device /dev/sdc1 is mounted (udisks-error-quark, 14)

    Continua a esserci:

    bpxroot@hpebian:~$ findmnt /dev/sdc1
    TARGET SOURCE FSTYPE OPTIONS
    /media/bpxroot/CCCOMA_X64F /dev/sdc1 vfat rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro


    Boh, magari è un problema di questo sistema, ma usando eject tutto il giro funziona, senza dare sudo e usando anche un'altra chiavetta.

    bpxroot@hpebian:~$ eject /dev/sdc
    bpxroot@hpebian:~$

    bpxroot@hpebian:~$ fdisk -l | grep Disk\ /dev/sdc
    bpxroot@hpebian:~$

    bpxroot@hpebian:~$ findmnt /dev/sdc1
    bpxroot@hpebian:~$

    bpxroot@hpebian:~$ eject -t /dev/sdc
    bpxroot@hpebian:~$

    bpxroot@hpebian:~$ fdisk -l | grep Disk\ /dev/sdc
    Disk /dev/sdc: 7,46 GiB, 8004829184 bytes, 15634432 sectors

    bpxroot@hpebian:~$ findmnt /dev/sdc1
    TARGET SOURCE FSTYPE OPTIONS
    /media/bpxroot/CCCOMA_X64F /dev/sdc1 vfat rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro


    Ciao

    Il giorno mar 29 ago 2023 alle ore 23:48 Davide Prina <Davide.Prina@null.net> ha scritto:

    Beppe Cantanna ha scritto:

    Paolo Redaelli ha scritto:

    Se fai eject non lo vedrai mai. In alcuni casi la periferica viene
    anche disalimentata.

    in effetti eject -t potrebbe non funzionare
    $ man eject
    [...]
    -t, --trayclose
    With this option the drive is given a CD-ROM tray close
    command. Not all devices support this command.
    [...]


    dai il comando "eject /dev/sdc" il device non viene più visto,
    pur essendo ancora elencato da lsusb, ma comunque successivamente
    puoi riagganciarlo dando il comando eject -t /dev/sdc.

    interessante, anche interessanti le prove che hai fatto con il
    login.

    Però, secondo me, il disco USB non dovrebbe essere caricato prima
    del login dell'utente. Se si collega qualcuno in SSH dovrebbe essere
    lui a compiere l'operazione, se ne ha i permessi.

    il comando umount, che oltretutto richiede un profilo amministrativo,

    non è detto, se non erro attualmente l'utente principale non
    amministratore ha il privilegio per fare il mount/unmount
    Se non erro dovrebbe essere installato il pacchetto pmount che permette proprio di fare questa operazione

    Aggiungo un'altra informazione interessante.
    Visto che ora c'è systemd si possono usare anche i comandi:

    per smontare il disco:
    $ udisksctl unmount -b /dev/sdc1

    per togliergli l'alimentazione
    $ udisksctl power-off -b /dev/sdc

    Poi non so se sia possibile rifornire l'alimentazione o bisogni
    toglierlo e rimettere la penna USB.

    Ciao
    Davide

    --
    La mia privacy non è affar tuo
    https://noyb.eu/it
    - You do not have my permission to use this email to train an AI -
    If you use this to train your AI than you accept to distribuite under AGPL license >= 3.0 all the model trained, all the source you have used to training your model and all the source of the program that use that model



    --
    *CANTANNA Giuseppe*
    cel. +39 349 1998700
    giuseppe.cantanna@glugto.org
    cantanna@glugto.org
    cantanna@gmail.com

    bproot.bc - Linux user n. 502620 registered on http://counter.li.org/
    *Nodo NINUX: *broot*.*


    *Per favore non inviatemi allegati in formato MS
    Office.​​Utilizza​te​ alternativamente documenti in formato OpenDocument.*
    ​
    http://en.wikipedia.org/wiki/OpenDocument <http://en.wikipedia.org/wiki/OpenDocument>
    ​ ​
    http://it.wikipedia.org/wiki/OpenDocument


    *​*http://www.documentfoundation.org/
    * ​ *https://it.libreoffice.org/
    ​ ​

    <div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace"><div style="margin-left:40px"><span class="gmail-im">&gt;&gt; Se fai eject non lo vedrai mai. In alcuni casi la periferica viene</span><br><span class="gmail-im">
    &gt;&gt; anche disalimentata.</span><br><span class="gmail-im"> </span><br><span class="gmail-im"></span>
    in effetti eject -t potrebbe non funzionare<br>
    $ man eject<br>
    [...]<br>
  • From Felipe Salvador@21:1/5 to franchi@modula.net on Wed Aug 30 09:30:01 2023
    On Mon, Aug 21, 2023 at 04:59:02PM +0200, franchi@modula.net wrote:
    Salve a tutti.

    Rilevo questo stranezza quando collego dischi Usb:

    Caso A)
    Sul monitor Vga del server presente la videata di login di Gnome e l'operatore, senza fare login, collega un disco esterno Usb formattato
    Ext4.
    Mi collego al server con Ssh e non vedo alcun disco esterno connesso.
    Ovvero, non lo vedo listato in /dev/disk/by-uuid n in
    /dev/disk/by-id.

    Caso B)
    Sul monitor Vga del server presente la videata di login a caratteri
    e l'operatore, senza fare login, collega lo stesso disco esterno sulla
    stessa porta Usb.
    Mi collego al server con Ssh e vedo che il disco esterno Usb
    connesso. Ovvero, lo vedo listato sia in /dev/disk/by-uuid che in /dev/disk/by-id.

    Non ho pieno controllo sul server remoto: mi devo fidare di quello che
    mi dice l'operatore e quindi ci potrebbero essere anche altre cause.

    Qualcuno si mai imbattuto in qualcosa di simile?

    Luciano

    Buongiorno,
    la mia ipotesi che questo comportamento sia "cortesia" di systemd e affiliati. Tutto il software che si occupa di gestire le periferiche,
    negli anni cambiato, per cui ora vincolato all'ambiente in uso e
    agli utenti che sono o non sono loggati. Per questo secondo me hai due comportamenti diversi fra il DE e il terminale.

    Saluti

    --

    Felipe Salvador

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Davide Prina@21:1/5 to All on Wed Aug 30 18:30:01 2023
    Beppe Cantanna ha scritto:

    bpxroot@hpebian:~$ /usr/bin/udisksctl unmount -b /dev/sdc
    Object /org/freedesktop/UDisks2/block_devices/sdc is not a mountable filesystem.

    dovevi indicare sdc1 o la partizione montanta se diversa da 1

    bpxroot@hpebian:~$ sudo /usr/bin/udisksctl power-off -b /dev/sdc
    Error powering off drive: The drive in use: Device /dev/sdc1 is mounted (udisks-error-quark, 14)

    infatti qui ti da l'errore dicendoti che sdc1 è montata 

    Ciao
    Davide
    ​ ​
    --
    La mia privacy non è affar tuo
    https://noyb.eu/it
    - You do not have my permission to use this email to train an AI -
    If you use this to train your AI than you accept to distribute under AGPL license >= 3.0 all the model trained, all the source you have used to
    training your model and all the source of the program that use that model

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Beppe Cantanna@21:1/5 to All on Wed Aug 30 21:10:01 2023
    bpxroot@hpebian:~$ /usr/bin/udisksctl unmount -b /dev/sdc
    Object /org/freedesktop/UDisks2/block_devices/sdc is not a mountable
    filesystem.

    dovevi indicare sdc1 o la partizione montanta se diversa da 1

    bpxroot@hpebian:~$ sudo /usr/bin/udisksctl power-off -b /dev/sdc
    Error powering off drive: The drive in use: Device /dev/sdc1 is mounted
    (udisks-error-quark, 14)

    infatti qui ti da l'errore dicendoti che sdc1 è montata

    sì, errore che non si ha usando eject nelle stesse condizioni, senza
    profilo amministrativo, esattamente come se operassi da DE. Successivamente posso ripristinare il disco con *eject -t **/dev/sdc*, senza dover sfilare fisicamente la chiavetta usb.



    Il giorno mer 30 ago 2023 alle ore 18:28 Davide Prina <Davide.Prina@null.net> ha scritto:

    Beppe Cantanna ha scritto:

    bpxroot@hpebian:~$ /usr/bin/udisksctl unmount -b /dev/sdc
    Object /org/freedesktop/UDisks2/block_devices/sdc is not a mountable
    filesystem.

    dovevi indicare sdc1 o la partizione montanta se diversa da 1

    bpxroot@hpebian:~$ sudo /usr/bin/udisksctl power-off -b /dev/sdc
    Error powering off drive: The drive in use: Device /dev/sdc1 is mounted
    (udisks-error-quark, 14)

    infatti qui ti da l'errore dicendoti che sdc1 è montata

    Ciao
    Davide
    ​ ​
    --
    La mia privacy non è affar tuo
    https://noyb.eu/it
    - You do not have my permission to use this email to train an AI -
    If you use this to train your AI than you accept to distribute under AGPL license >= 3.0 all the model trained, all the source you have used to training your model and all the source of the program that use that model



    --
    *CANTANNA Giuseppe*
    cel. +39 349 1998700
    giuseppe.cantanna@glugto.org
    cantanna@glugto.org
    cantanna@gmail.com

    bproot.bc - Linux user n. 502620 registered on http://counter.li.org/
    *Nodo NINUX: *broot*.*


    *Per favore non inviatemi allegati in formato MS
    Office.​​Utilizza​te​ alternativamente documenti in formato OpenDocument.*
    ​
    http://en.wikipedia.org/wiki/OpenDocument <http://en.wikipedia.org/wiki/OpenDocument>
    ​ ​
    http://it.wikipedia.org/wiki/OpenDocument


    *​*http://www.documentfoundation.org/
    * ​ *https://it.libreoffice.org/
    ​ ​

    <div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace"><div style="margin-left:40px"><span class="gmail-im">&gt; bpxroot@hpebian:~$ /usr/bin/udisksctl unmount -b /dev/sdc</span><br><span class="gmail-im">
    &gt; Object /org/freedesktop/UDisks2/block_devices/sdc is not a mountable filesystem.</span><br><span class="gmail-im">
    </span><br><span class="gmail-im"></span>
    dovevi indicare sdc1 o la partizio