Scalone ikony i brak osobnych punktów montowania dla dwóch dysków 4TB w Ubuntu Focal

[Benita]

Mam problem z menedżerem plików Nautilus w Ubuntu 20.04 Focal. W komputerze posiadam dwa fizyczne dyski HDD Toshiba po 4TB każdy (sda oraz sdb), a system stoi na dysku NVMe.
Po poprawnym sformatowaniu nowego dysku w programie GParted do systemu plików ext4 (z tablicą partycji GPT i wyrównaniem do MiB), menedżer plików zaczął traktować oba dyski tak, jakby były jednym i tym samym urządzeniem.
Aktualne objawy:

Po otwarciu obu dysków z zakładki „Inne lokalizacje”, na głównym pasku programów Ubuntu pojawia się tylko jedna wspólna ikona dla obu napędów, zamiast dwóch osobnych.
W oknie Nautilusa, na lewym panelu bocznym pod sekcją „Inne”, otwarte dyski nie tworzą osobnych wpisów z ikonami wysuwania (trójkącikami).
Na wspólnej ikonie na pasku zadań brakuje niezależnych opcji „Zatrzymaj i odepnij bezpiecznie”.

Plik /etc/fstab jest czysty (ręczne wpisy zostały usunięte), błędy kabli (CRC) w SMART wynoszą 0, a usługa udisks2 była restartowana, jednak system wciąż błędnie współdzieli lub zapętla punkty montowania w GVfs dla obu tych woluminów. Nie chcę, aby te dyski montowały się automatycznie przy starcie systemu – zależy mi na przywróceniu domyślnego zachowania, gdzie każdy budzi się osobnym kliknięciem w „Innych lokalizacjach” i ma swój własny wpis w drzewie katalogów oraz osobną ikonę na pasku.
Co może być przyczyną takiego zachowania i jak trwale wyczyścić ten zacięty cache montowania?

[kobrawerde]

a podaj co pokażą komendy:

Kod: Zaznacz cały

lsblk -f
sudo blkid

Dwa dyski ext4 nie mogą mieć tych samych UUID.
1 - Jeżeli widzisz duplikaty — to jest źródło problemu.

2 - Zdublowany GPT disk GUID
Sprawdź:

Kod: Zaznacz cały

sudo sgdisk -p /dev/sda
sudo sgdisk -p /dev/sdb

Jeżeli „Disk identifier (GUID)” jest taki sam to np:

Kod: Zaznacz cały

sudo sgdisk -G /dev/sdb

To generuje nowy GUID GPT dla dysku.

W celu diagnostyki możesz podać też :

Kod: Zaznacz cały

lsblk -o NAME,FSTYPE,LABEL,UUID,PARTUUID,MOUNTPOINT
gio mount -l

W necie wyczytałem też a chyba masz taki system :
Bug GVfs w Ubuntu 20.04
Focal miał kilka znanych problemów z:
gvfs
nautilus
udisks2
szczególnie po ręcznych operacjach w GParted.
Warto zaktualizować:

Kod: Zaznacz cały

sudo apt update
sudo apt full-upgrade

[Benita]

Dziękuję za szczegółowe wskazówki techniczne.
Weryfikacja za pomocą lsblk -f została przeprowadzona i nie ma mowy o duplikacie UUID. Każda partycja ma swój unikalny identyfikator:

/dev/sda1 (nowy): dc890e4a-f5c8-4d89-9187-b06c3668da29
/dev/sdb1 (stary): 36d0faaf-a42d-48d6-b7c3-eb85f8525eb4

Problem z zacytowanym bugiem w GVfs i udisks2 w Ubuntu 20.04 Focal okazał się jednak trafiony w dziesiątkę. Po sformatowaniu nowego dysku w GParted do ext4, menedżer plików (Nautilus) całkowicie zgłupiał, ponieważ obie partycje miały pustą kolumnę LABEL. Przez brak etykiet system graficzny przypisał im identyczną, zastępczą nazwę „Wolumin 4TB” i scalił punkty montowania w pamięci podręcznej GVfs pod jednym węzłem.
Rozwiązanie, które ostatecznie pomogło:
Za pomocą narzędzia e2label nadałam obu partycjom unikalne nazwy bezpośrednio na strukturze plików:

sudo e2label /dev/sda1 FangFei
sudo e2label /dev/sdb1 Wolumin

Po nadaniu etykiet, wyczyszczeniu pliku /etc/fstab z wcześniejszych, testowych wpisów i restarcie usługi udisks2, system w końcu rozdzielił urządzenia. Na głównym pasku programów pojawiły się dwie niezależne ikony dysków, a w zakładce „Inne lokalizacje” oba woluminy są widoczne pod swoimi właściwymi nazwami.
Jedyna różnica w porównaniu do stanu sprzed awarii polega na tym, że w Nautilusie ikona bezpiecznego wysunięcia (trójkącik) wyświetla się teraz po prawej stronie w sekcji głównej okna, zamiast bezpośrednio przy nazwie na lewym panelu bocznym. Najważniejsze jednak, że oba dyski działają w pełni autonomicznie, nie montują się automatycznie przy starcie (co było kluczowe) i można je bezpiecznie odpinać bez podawania hasła roota.

Problem z panelem bocznym i zakładkami: Dyski po otwarciu z „Innych lokalizacji” nadal nie meldują się automatycznie w lewej kolumnie Nautilusa z ikoną wysunięcia. Próba obejścia tego przez skrót Ctrl+D tworzy martwe zakładki – po kliknięciu w nie na panelu bocznym nic się nie dzieje, system nie potrafi przejść do ścieżki.

W celu pełnej diagnostyki podaję zrzuty z poleceń:
Wynik lsblk -o NAME,FSTYPE,LABEL,UUID,PARTUUID,MOUNTPOINT:
lsblk -o NAME,FSTYPE,LABEL,UUID,PARTUUID,MOUNTPOINT | grep -E "NAME|sd"
NAME FSTYPE LABEL UUID PARTUUID MOUNTPOINT
sda
└─sda1 ext4 FangFei dc890e4a-f5c8-4d89-9187-b06c3668da29 e9d131c9-f7ea-4a56-bbb6-75c6aa9940cb
sdb
└─sdb1 ext4 36d0faaf-a42d-48d6-b7c3-eb85f8525eb4 26a9a29d-df68-4934-9921-ba691e37006b

Wynik gio mount -l:
Drive(0): PNY CS3030 250GB SSD
Type: GProxyDrive (GProxyVolumeMonitorUDisks2)
Drive(1): TOSHIBA HDWG440
Type: GProxyDrive (GProxyVolumeMonitorUDisks2)
Volume(0): FangFei
Type: GProxyVolume (GProxyVolumeMonitorUDisks2)
Drive(2): TOSHIBA HDWE140
Type: GProxyDrive (GProxyVolumeMonitorUDisks2)
Volume(0): Wolumin (4,0 TB)
Type: GProxyVolume (GProxyVolumeMonitorUDisks2)
Drive(3): HL-DT-ST DVDRAM GH24NSD5
Type: GProxyDrive (GProxyVolumeMonitorUDisks2)
Volume(0): Unisoc Phone
Type: GProxyVolume (GProxyVolumeMonitorMTP)
Mount(0): Unisoc Phone -> mtp://Unisoc_Unisoc_Phone_2024050304/
Type: GProxyShadowMount (GProxyVolumeMonitorMTP)
Mount(1): mtp -> mtp://Unisoc_Unisoc_Phone_2024050304/
Type: GDaemonMount

Dodatkowo uprawnienia katalogu montowania (ls -la /media/fangfei):
razem 8
drwxr-x---+ 2 root root 4096 maj 21 23:16 .
drwxr-xr-x 3 root root 4096 maj 21 18:42 ..

Bardzo proszę o pomoc, jak bezpiecznie przywrócić domyślne uprawnienia zapisu dla użytkownika oraz zmusić Nautilusa do prawidłowego wyświetlania punktów montowania na lewym pasku.

[kobrawerde]

może :

Kod: Zaznacz cały

nautilus -q

Kod: Zaznacz cały

rm -f ~/.config/gtk-3.0/bookmarks

Kod: Zaznacz cały

rm -rf ~/.local/share/gvfs-metadata
rm -rf ~/.cache/gvfs

Zrestartuj komponenty GVfs

Kod: Zaznacz cały

killall gvfsd gvfsd-fuse gvfs-udisks2-volume-monitor

Uruchom ponownie monitor:

Kod: Zaznacz cały

/usr/lib/gvfs/gvfs-udisks2-volume-monitor &

Bardzo ważne — usuń stare mountpointy użytkownika
Sprawdź:

Kod: Zaznacz cały

ls -la /media/$USER

Jeżeli są stare katalogi po wcześniejszych testach:

Kod: Zaznacz cały

sudo rm -rf /media/$USER/*

tylko gdy NIE są aktualnie zamontowane. !!

Kod: Zaznacz cały

reboot

Dodatkowo sprawdź jedną rzecz
Uruchom:

Kod: Zaznacz cały

gio mount -l

powinno być... oba dyski jako osobne mounty typu:

Kod: Zaznacz cały

Mount(0): Toshiba_A -> file:///media/user/Toshiba_A
Mount(1): Toshiba_B -> file:///media/user/Toshiba_B

Jeżeli tam są poprawnie widoczne, a sidebar nadal ich nie pokazuje, to problem siedzi wyłącznie w konfiguracji Nautilusa/GTK użytkownika.
Ostateczny reset GNOME Files (najskuteczniejszy)
Jeżeli nadal będzie źle:

Kod: Zaznacz cały

dconf reset -f /org/gnome/nautilus/

i:

Kod: Zaznacz cały

rm -rf ~/.config/nautilus

To resetuje cały stan GUI menedżera plików i zwykle przywraca prawidłowy sidebar.


Dodatkowo z informacji diagnostycznych w terminalu :
Problem nr 1 — błędny katalog /media/fangfei
Normalnie /media/fangfei powinno wyglądać mniej więcej tak:

Kod: Zaznacz cały

drwxr-xr-x root root /media/fangfei

a katalogi dysków pod nim powinny być dynamicznie tworzone przez udisks2.

Tymczasem u Ciebie najwyraźniej został wcześniej ręcznie utworzony lub „skażony” ACL
Bezpieczna naprawa
1. Odmontuj oba dyski

Kod: Zaznacz cały

udisksctl unmount -b /dev/sda1
udisksctl unmount -b /dev/sdb1

Usuń uszkodzony katalog użytkownika z /media
UWAGA: tylko katalog montowania, nie dane z dysków.

Kod: Zaznacz cały

sudo rm -rf /media/fangfei

To jest bezpieczne, jeśli dyski są odmontowane.
Odtwórz poprawny katalog bazowy

Kod: Zaznacz cały

sudo mkdir /media/fangfei
sudo chown root:root /media/fangfei
sudo chmod 755 /media/fangfei

Usuń ACL
To bardzo ważne:

Kod: Zaznacz cały

sudo setfacl -b /media/fangfei

Sprawdź:

Kod: Zaznacz cały

getfacl /media/fangfei

Powinno być tylko klasyczne:
user::rwx
group::r-x
other::r-x
Wyczyść runtime GVfs

Kod: Zaznacz cały

rm -rf ~/.local/share/gvfs-metadata
rm -rf ~/.cache/gvfs
nautilus -q
killall gvfsd gvfsd-fuse gvfs-udisks2-volume-monitor

Restart usług

Kod: Zaznacz cały

sudo systemctl restart udisks2
reboot

Jeszcze jedna ważna rzecz
Widzę:
sdb1 ext4 36d0faaf...
bez LABEL.
To nie jest błąd krytyczny, ale Nautilus dużo lepiej działa, gdy każdy dysk ma LABEL.
Nadaj drugiemu HDD jakąś nazwę np :

Kod: Zaznacz cały

sudo e2label /dev/sdb1 Toshiba_B

Potem:

sudo blkid

sprawdź, czy oba mają:

różne LABEL,
różne UUID,
różne PARTUUID.

To stabilizuje działanie GVfs.
powodzenia bo dużo kombinowania

[Benita]

Zrobiłam dokładnie dwie pierwsze części planu (reset Nautilusa, GTK, GVfs oraz czyszczenie runtime). Komenda ls -la /media/$USER wykazała, że katalog był całkowicie pusty (tylko kropki systemowe), więc bezpiecznie wykonałam też sudo rm -rf /media/$USER/*. Następnie zrestartowałam komputer.
Niestety, po ponownym uruchomieniu w menedżerze plików sytuacja z lewym panelem bocznym i kopiowaniem się nie zmieniła.
Zatrzymałam się przed wykonaniem ostatniej części instrukcji (tej z usuwaniem całego katalogu bazowego przez sudo rm -rf /media/fangfei i czyszczeniem ACL). Powiem szczerze: na starym dysku mam bezcenne, unikalne zdjęcia i filmy z moją mamą. Koszmarnie boję się używania polecenia rm -rf na poziomie katalogu /media – panicznie obawiam się, że jeśli system z jakiegoś powodu źle zinterpretuje stan montowania w tle, stracę te pamiątki.

W związku z tym mam pytanie o alternatywne, w 100% bezpieczne rozwiązanie: czy zamiast walczyć z tym skażonym uprawnieniami i blokadami ACL folderem /media/fangfei, nie moglibyśmy po prostu całkowicie przenieść punktów montowania obu dysków do innego, czystego katalogu systemowego – na przykład do /mnt?
Myślałam o ręcznym stworzeniu tam osobnych folderów, np.:
/mnt/FangFei oraz /mnt/Wolumin
i przepisaniu ich własności na użytkownika przez chown, aby odblokować tradycyjne kopiowanie (PPM -> Kopiuj -> Wklej), omijając całkowicie kapryśny podsystem GVfs w /media.
Czy takie rozwiązanie z przeniesieniem montowania do /mnt jest technicznie poprawne i bezpieczne dla moich danych? Jak najlepiej to teraz skonfigurować, żeby odzyskać pełne prawa zapisu i stabilny dostęp z poziomu okien?

Czy wpisanie w terminalu komendy:
sudo apt install --reinstall nautilus gvfs gvfs-backends udisks2 -y
ma szansę zadziałać jak automatyczna "naprawa systemu"? Czy skrypty instalacyjne Ubuntu same nadpiszą uszkodzone uprawnienia katalogu bazowego /media i zresetują błędy Nautilusa do stanu fabrycznego bez dotykania moich plików?

Będę bardzo wdzięczna za opinię, które z tych rozwiązań jest najmniej ryzykowne? Nie mogę stracić plików.

[kobrawerde]

może wystarczy ....Odmontuj oba dyski

Kod: Zaznacz cały

udisksctl unmount -b /dev/sda1
udisksctl unmount -b /dev/sdb1

Sprawdź co faktycznie siedzi w /media/fangfei

Kod: Zaznacz cały

ls -la /media/fangfei

Jeżeli są tam:
katalogi z danymi,
ręczne backupy,
własne pliki,
to NICZEGO nie usuwaj.
Usuń tylko ACL i napraw prawa
To jest sedno problemu.Usuń ACL:

Kod: Zaznacz cały

sudo setfacl -Rb /media/fangfei

Przywróć klasyczne prawa:

Kod: Zaznacz cały

sudo chmod 755 /media/fangfei
sudo chown root:root /media/fangfei

Sprawdź wynik

Kod: Zaznacz cały

ls -ld /media/fangfei
getfacl /media/fangfei

Powinno wyglądać mniej więcej tak:
drwxr-xr-x root root
bez znaku +
Wyczyść tylko cache GVfs
To bezpieczne:

Kod: Zaznacz cały

rm -rf ~/.local/share/gvfs-metadata
rm -rf ~/.cache/gvfs

Restart komponentów

Kod: Zaznacz cały

nautilus -q
killall gvfsd gvfsd-fuse gvfs-udisks2-volume-monitor
sudo systemctl restart udisks2

reboot ...restart stystemu

Ps. czy to problem z ACL/cache starego /media/fangfei...można przetestować wcześniej tak:
Utwórz testowy katalog:

Kod: Zaznacz cały

sudo mkdir /media/testmount
sudo chmod 755 /media/testmount

Zamontuj ręcznie jeden dysk:

Kod: Zaznacz cały

udisksctl mount -b /dev/sda1

lub:

Kod: Zaznacz cały

sudo mount /dev/sda1 /media/testmount

Jeżeli wtedy Nautilus zacznie poprawnie pokazywać sidebar, to potwierdzi problem z ACL/cache starego /media/fangfei

[Benita]

Zrobiłam test z udisksctl mount -b /dev/sda1. System nie zamontował dysku w /media, tylko automatycznie wyrzucił go do ścieżki /mnt/dc890e4a-f5c8-4d89-9187-b06c3668da29. Wygląda na to, że katalog /media/fangfei jest czysty, a udisks2 z jakiegoś powodu traktuje te partycje jako stałe woluminy systemowe i ukrywa je przed sidebar_em.

Wynik:
fangfei@fangfei-desktop:~$ sudo mkdir /media/testmount
[sudo] hasło użytkownika fangfei:
fangfei@fangfei-desktop:~$ udisksctl mount -b /dev/sda1
Mounted /dev/sda1 at /mnt/dc890e4a-f5c8-4d89-9187-b06c3668da29.
fangfei@fangfei-desktop:~$

[kobrawerde]

albo może podaj :

Kod: Zaznacz cały

udisksctl info -b /dev/sda1

Interesują szczególnie pola:
HintSystem:
HintAuto:
HintIgnore:
HintName:
IdLabel:
Jeżeli zobaczysz np.:
HintSystem: true
albo:
HintAuto: false
to właśnie znaleźliśmy problem.
Możliwe, że partycja została oznaczona jako „systemowa”
Czasem po GParted lub ręcznych operacjach GPT zostają ustawione flagi typu:
hidden,
noauto,
system partition.
inne informacje:

Kod: Zaznacz cały

sudo parted /dev/sda print
sudo gdisk -l /dev/sda

Szukaj nietypowych flag lub typów partycji innych niż standardowe Linux filesystem (8300).


Jeśli dalej to nie to ....to może jednak coś nie tak z : gvfs-udisks2-volume-monitor
może przeinstaluj komponenty GVfs

Kod: Zaznacz cały

sudo apt install --reinstall gvfs gvfs-common gvfs-daemons gvfs-backends

Kod: Zaznacz cały

sudo apt install --reinstall udisks2

Potem usuń runtime GVfs

Kod: Zaznacz cały

rm -rf ~/.cache/gvfs
rm -rf ~/.local/share/gvfs-metadata

Restart usług

Kod: Zaznacz cały

nautilus -q
killall gvfsd gvfsd-fuse gvfs-udisks2-volume-monitor
sudo systemctl restart udisks2

reboot ...restart systemu

[Benita]

Wklejam poniżej pełne wyniki poleceń.
W poleceniu udisksctl info wyszły dokładnie te zablokowane flagi:

HintAuto: false
HintSystem: true

Co ciekawe, w sekcji Configuration system wciąż widzi i pamięta konfigurację fstab ze ścieżką /mnt/ oraz opcjami nosuid,nodev,nofail,x-gvfs-show,noauto, mimo że fizyczny plik /etc/fstab został przeze mnie sprawdzony w edytorze nano i wyczyszczony. Wygląda na to, że te błędne opcje montowania zagnieździły się w pamięci wewnętrznej usługi udisks2 i to one wymuszają status dysku systemowego, ukrywając go przed sidebar_em.
Z kolei parted i gdisk potwierdzają, że sama partycja GPT jest całkowicie zdrowa, ma prawidłowy kod 8300 (Linux filesystem) i nie posiada żadnych ukrytych flag sprzętowych.
Jak teraz najbezpieczniej zmusić usługę udisks2, aby całkowicie wymazała tę zablokowaną konfigurację fstab i zaczęła traktować ten wolumin jako zwykły dysk wymienny z powrotem w katalogu /media? Chyba, że tak może zostać??? Nie jest to jakiś błąð?

fangfei@fangfei-desktop:~$ udisksctl info -b /dev/sda1
/org/freedesktop/UDisks2/block_devices/sda1:
org.freedesktop.UDisks2.Block:
Configuration: [('fstab', {'fsname': <b'/dev/disk/by-uuid/dc890e4a-f5c8-4d89-9187-b06c3668da29'>, 'dir': <b'/mnt/dc890e4a-f5c8-4d89-9187-b06c3668da29'>, 'type': <b'auto'>, 'opts': <b'nosuid,nodev,nofail,x-gvfs-show,noauto'>, 'freq': <0>, 'passno': <0>})]
CryptoBackingDevice: '/'
Device: /dev/sda1
DeviceNumber: 2049
Drive: '/org/freedesktop/UDisks2/drives/TOSHIBA_HDWG440_83U0A00VFZ0G'
HintAuto: false
HintIconName:
HintIgnore: false
HintName:
HintPartitionable: true
HintSymbolicIconName:
HintSystem: true
Id: by-id-ata-TOSHIBA_HDWG440_83U0A00VFZ0G-part1
IdLabel: FangFei
IdType: ext4
IdUUID: dc890e4a-f5c8-4d89-9187-b06c3668da29
IdUsage: filesystem
IdVersion: 1.0
MDRaid: '/'
MDRaidMember: '/'
PreferredDevice: /dev/sda1
ReadOnly: false
Size: 4000785104896
Symlinks: /dev/disk/by-id/ata-TOSHIBA_HDWG440_83U0A00VFZ0G-part1
/dev/disk/by-id/wwn-0x5000039cb8d3068c-part1
/dev/disk/by-label/FangFei
/dev/disk/by-partlabel/FangFei2
/dev/disk/by-partuuid/e9d131c9-f7ea-4a56-bbb6-75c6aa9940cb
/dev/disk/by-path/pci-0000:00:17.0-ata-3-part1
/dev/disk/by-uuid/dc890e4a-f5c8-4d89-9187-b06c3668da29
UserspaceMountOptions:
org.freedesktop.UDisks2.Filesystem:
MountPoints:
Size: 4000785104896
org.freedesktop.UDisks2.Partition:
Flags: 0
IsContained: false
IsContainer: false
Name: FangFei2
Number: 1
Offset: 1048576
Size: 4000785104896
Table: '/org/freedesktop/UDisks2/block_devices/sda'
Type: 0fc63daf-8483-4772-8e79-3d69d8477de4
UUID: e9d131c9-f7ea-4a56-bbb6-75c6aa9940cb

fangfei@fangfei-desktop:~$ sudo parted /dev/sda print
[sudo] hasło użytkownika fangfei:
Model: ATA TOSHIBA HDWG440 (scsi)
Dysk /dev/sda: 4001GB
Rozmiar sektora (logiczny/fizyczny): 512B/512B
Tablica partycji: gpt
Flagi dysku:

Numer Początek Koniec Rozmiar System plików Nazwa Flaga
1 1049kB 4001GB 4001GB ext4 FangFei2

fangfei@fangfei-desktop:~$ sudo gdisk -l /dev/sda
GPT fdisk (gdisk) version 1.0.5

Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 7814037168 sectors, 3.6 TiB
Model: TOSHIBA HDWG440
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 61D07994-68F7-4F12-818F-45EC021D3281
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 7814037134
Partitions will be aligned on 2048-sector boundaries
Total free space is 3693 sectors (1.8 MiB)

Number Start (sector) End (sector) Size Code Name
1 2048 7814035455 3.6 TiB 8300 FangFei2

[kobrawerde]

1. Sprawdź czy naprawdę nie ma wpisu w /etc/fstab

Kod: Zaznacz cały

cat /etc/fstab

upewnij się, że NIE MA:

UUID dysku,
/mnt/dc890...,
x-gvfs-show,
noauto.


potem spróbuj

Kod: Zaznacz cały

sudo mv /mnt/dc890e4a-f5c8-4d89-9187-b06c3668da29 \
/mnt/dc890e4a-f5c8-4d89-9187-b06c3668da29.old

Zrób tak samo dla drugiego dysku, jeśli istnieje podobny katalog.
Potem restart usług

Kod: Zaznacz cały

nautilus -q
killall gvfsd gvfsd-fuse gvfs-udisks2-volume-monitor
sudo systemctl restart udisks2

restart systemu
otwórz Nautilus
„Inne lokalizacje”
kliknij dysk.
.....................
Jeżeli:
kiedyś istniał wpis fstab,
to mountpoint nadal istnieje,
UUID pasuje, to daemon uznaje urządzenie za „system-managed volume” (HintSystem: true) i przestaje traktować je jak zwykły dysk użytkownika GNOME.
Ps .
Z diagnostyki wynika, że:
GPT jest poprawne,
typ partycji 8300 jest prawidłowy,
UUID są unikalne,
brak błędów SMART,
ext4 jest OK,
udisks2 widzi dyski poprawnie.
Czyli problem jest praktycznie wyłącznie w warstwie desktopowej GNOME.
To wygląda jak klasyczny bug state/cache desktop stack Ubuntu 20.04. .... może czas na nowszą wersję

[Benita]

Wynik polecenia cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/nvme0n1p2 during installation
UUID=52cac1c4-310f-4c5d-a47a-835bc2924da5 / ext4 errors=remount-ro 0 1
# /boot/efi was on /dev/nvme0n1p1 during installation
UUID=7535-5100 /boot/efi vfat umask=0077 0 1
/swapfile none swap sw 0 0
/dev/disk/by-uuid/36d0faaf-a42d-48d6-b7c3-eb85f8525eb4 /mnt/36d0faaf-a42d-48d6-b7c3-eb85f8525eb4 auto nosuid,nodev,nofail,x-gvfs-show,noauto 0 0
/dev/disk/by-uuid/dc890e4a-f5c8-4d89-9187-b06c3668da29 /mnt/dc890e4a-f5c8-4d89-9187-b06c3668da29 auto nosuid,nodev,nofail,x-gvfs-show,noauto 0 0

Te wpisy tam są... ??? i to dla obu dysków kierujące do /mnt/. Boję się sama usuwać te linie edytorem nano, żeby nic nie popsuć w danych na starym dysku. Czy mam je wyciąć za pomocą Ctrl+K, ? Jest to bezpieczne? I potem zastosowac pozostałe dwa wpisy?

[kobrawerde]

Najbezpieczniejsza procedura
1. Zrób backup fstab

Kod: Zaznacz cały

sudo cp /etc/fstab /etc/fstab.backup

2. Otwórz plik do edycji

Najprościej:

Kod: Zaznacz cały

sudo nano /etc/fstab

lub prościej inny edytor graficzny z prawami root-a
3. Usuń TYLKO te dwie linie

Usuń dokładnie:

Kod: Zaznacz cały

/dev/disk/by-uuid/36d0faaf-a42d-48d6-b7c3-eb85f8525eb4 /mnt/36d0faaf-a42d-48d6-b7c3-eb85f8525eb4 auto nosuid,nodev,nofail,x-gvfs-show,noauto 0 0

/dev/disk/by-uuid/dc890e4a-f5c8-4d89-9187-b06c3668da29 /mnt/dc890e4a-f5c8-4d89-9187-b06c3668da29 auto nosuid,nodev,nofail,x-gvfs-show,noauto 0 0

NIC więcej.
zapisz : Ctrl+X ...t...enter
Sprawdź poprawność fstab

Bardzo ważne:

Kod: Zaznacz cały

sudo mount -a

Jeśli brak błędów → wszystko OK.
Restart usług

Kod: Zaznacz cały

nautilus -q
killall gvfsd gvfsd-fuse gvfs-udisks2-volume-monitor
sudo systemctl restart udisks2

reboot ...restart systemu

[Benita]

Zrobiłam wszystko dokładnie według instrukcji. Backup zrobiony, dwie linie z fstab usunięte przez nano, komenda sudo mount -a przeszła idealnie bez żadnych błędów. Usługi zresetowane, system uruchomiony ponownie. Niestety, w oknie Nautilusa nadal nic się nie zmieniło – dyski po otwarciu z zakładki „Inne lokalizacje” nie wracają na lewy pasek boczny, a trójkąciki do odmontowania wciąż wyświetlają się tylko po prawej stronie w sekcji głównej okna. Wygląda na to, że usługa udisks2 nadal pamięta starą flagę HintSystem: true.

Z racji tego, że na starym dysku mam bezcenne pamiątki, mam bardzo ważne pytanie:
Czy jeśli zostawię ten układ dysków tak, jak jest teraz (czyli z trójkącikami po prawej stronie i statusem „dysków wewnętrznych/systemowych”), to czy taki montaż jest w pełni poprawny, dopuszczalny i bezpieczny dla sprzętu? Czy to nie wpłynie negatywnie na żywotność moich dwóch dysków Toshiba 4TB i czy moje pliki są tam na stałe bezpieczne?
Jeśli to tylko kwestia kosmetyki interfejsu graficznego i dyskom nic nie grozi, to zostawię ten układ już na zawsze, żeby nie ryzykować dalszego mieszania w systemie.

[kobrawerde]

gvfs-udisks2-volume-monitor zapamiętał stare wpisy jako:
„system mounts”
albo stale oznaczone HintSystem=true
i nie odświeża poprawnie modelu sidebaru nawet po zmianie konfiguracji.
To nie wpływa na bezpieczeństwo danych.

Opcja - zostawić jak jest
Szczerze: to jest rozsądne.
Bo funkcjonalnie:
wszystko działa,
dane są bezpieczne,
mounty są niezależne,
dyski nie startują automatycznie.
Problem jest kosmetyczny.

Opcja 2 — przejście na Ubuntu 22.04 LTS
To prawdopodobnie rozwiąże problem „samo”.
Ubuntu 22.04 ma:
dużo nowszy GNOME,
lepszy GVfs,
poprawione mount handling,
poprawione sidebar volumes.
I nadal jest lekkim, stabilnym LTS.

Opcja 3 — alternatywny menedżer plików
Możesz też sprawdzić:
Nemo /Caja /Thunar
One często:
lepiej współpracują z udisks2,
nie mają problemów sidebaru GNOME,
poprawnie pokazują eject buttons nawet na starszych Ubuntu.

Ps. Ja na Linux Mint mam : Nemo
możesz go przetestować czy będzie lepiej ?

Kod: Zaznacz cały

sudo apt install nemo

[Benita]

Wielkie dzięki za niesamowicie profesjonalną, fachową i przede wszystkim cierpliwą pomoc.

Zdecydowałam się posłuchać pierwszej rady i zostawiam ten układ dokładnie tak, jak jest obecnie. Skoro potwierdziłeś, że ta zmiana montowania w żaden sposób nie wpływa na bezpieczeństwo samych danych, a dyski działają cicho, niezależnie i nie startują same z systemem – nie będę na siłę niczego zmieniać ani instalować nowego menedżera.

Przymierzam się od jakiegoś czasu do przejścia na Meduzę (22.04 LTS), o której wspomniałeś, ale nie ukrywam, że po całej tej stresującej akcji z ikonami mam teraz ogromne obawy przed automatycznym przejściem z Focal na Jammy. Boję się, czy taki duży proces znowu czegoś nie namiesza w moich punktach montowania i uprawnieniach.

Jeszcze raz wielkie dzięki za profesjonalną pomoc. Pozdrawiam serdecznie!

[kobrawerde]

Nie ma się co obawiać . Zrób sobie backup partycji / dysku z obecnym systemem Ubuntu programem CloneZilla i potem spokojnie możesz instalować nowy system. Jak coś pójdzie nie tak lub nie będzie Ci "pasował" z jakiegoś powodu Ubuntu 22.04 to przywracasz backup i masz znowu 20.04