Hittar ingen mount point för extern hårddisk

Jag skapade en tråd för ett tag sedan gällande att min externa hårddisk hade en tendens att mata ut sig själv. Har tack vare svaren i den tråden fått disken att nu inte mata ut sig på flera veckor. Dock hände det för några dagar sedan igen. Jag använder Ubuntu Server på en NUC och disken är formaterad i exFAT.

När detta har hänt tidigare så har jag bara behövt köra rm -rf på mappen som disken mountas i och därefter startat om datorn. Jag märkte dock efter omstart att disken inte mountades igen.

När jag kör lsusb så får jag följande:

Bus 002 Device 002: ID 0bc2:331a Seagate RSS LLC Expansion Desk
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 8087:0aaa Intel Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Så den verkar dyka upp som en ansluten USB-enhet. Men kör jag sudo fdisk -l så dyker den externa disken inte upp i listan över diskar. Jag har även testat sudo lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT,LABEL men får även där inte upp den externa disken.

Har testat att ansluta disken till min Mac och där dyker den upp och fungerar utan problem.

Vad behöver jag göra för att få disken att mounta igen?

Jag har sedan tidigare svartlistat UAS genom att köra sudo sh -c 'echo blacklist uas >> /etc/modprobe.d/blacklist.conf', då det potentiellt kunde hjälpa att disken tidigare matade ut sig själv med jämna mellanrum.

Jag provade nu att ta bort blacklist uas och starta om. Då mountar disken korrekt. Så verkar som att det är det som är problemet. Konstigt nog har jag kunnat svartlista tidigare och få disken att mounta utan problem. Det hjälpte dessutom med problemet att disken matade ut sig då den sedan jag svartlistade har fortsatt vara mountad i flera veckor.

Vad jag vet så har inte disken någon support för SMART, tyvärr.

Kör Ubuntu Server utan GUI, så kan inte köra GParted. Men körde kommandot "print" i parted istället via terminalen och fick då att tabellen är "gpt". Här är infon jag fick i övrigt:
Model: Seagate Expansion Desk (scsi)
Disk /dev/sda: 14.0TB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number Start End Size File system Name Flags
1 20.5kB 210MB 210MB fat32 EFI System Partition boot, esp
2 211MB 14.0TB 14.0TB msftdata

Detta är vad jag får från lsblk:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop0 7:0 0 55.5M 1 loop /snap/core18/2284
loop1 7:1 0 55.5M 1 loop /snap/core18/2344
loop2 7:2 0 61.9M 1 loop /snap/core20/1376
loop3 7:3 0 61.9M 1 loop /snap/core20/1361
loop4 7:4 0 43.6M 1 loop /snap/snapd/15177
loop5 7:5 0 67.8M 1 loop /snap/lxd/22753
loop6 7:6 0 43.6M 1 loop /snap/snapd/14978
loop7 7:7 0 67.9M 1 loop /snap/lxd/22526
sda 8:0 0 12.8T 0 disk
├─sda1 8:1 0 200M 0 part
└─sda2 8:2 0 12.8T 0 part /media/bauta
nvme0n1 259:0 0 232.9G 0 disk
├─nvme0n1p1 259:1 0 512M 0 part /boot/efi
├─nvme0n1p2 259:2 0 1G 0 part /boot
└─nvme0n1p3 259:3 0 231.4G 0 part
└─ubuntu--vg-ubuntu--lv 253:0 0 100G 0 lvm /

Detta får jag från blkid. Här verkar inte den externa disken listas av någon anledning?:
/dev/nvme0n1p1: UUID="9892-56AC" TYPE="vfat" PARTUUID="4612bded-e43f-4490-89c4-1608e49053b6"
/dev/nvme0n1p2: UUID="5b7a1611-3265-4998-8e81-9385b976290f" TYPE="ext4" PARTUUID="0d12b4f6-fc29-4ebc-9bbb-bef0f79d97ff"
/dev/nvme0n1p3: UUID="ilgd1d-a1Mw-reXo-yUra-mjwQ-3ekv-N9gymo" TYPE="LVM2_member" PARTUUID="554e14cd-49ec-471d-809f-5c1db4aeeaf7"
/dev/mapper/ubuntu--vg-ubuntu--lv: UUID="532bba2a-c1a2-4204-96e9-6c63e6ece34f" TYPE="ext4"

Och sen /etc/fstab:
...
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/ubuntu-vg/ubuntu-lv during curtin installation
/dev/disk/by-id/dm-uuid-LVM-EkVZluNuqX6QAoD35TtGNzEvSUMi9NPqWqrCHUmnoILZJxDnQb2>
# /boot was on /dev/nvme0n1p2 during curtin installation
/dev/disk/by-uuid/5b7a1611-3265-4998-8e81-9385b976290f /boot ext4 defaults 0 1
# /boot/efi was on /dev/nvme0n1p1 during curtin installation
/dev/disk/by-uuid/9892-56AC /boot/efi vfat defaults 0 1
/swap.img none swap sw 0 0
UUID=605B-99E7 /media/bauta exfat rw,user,exec,umask=000 0 0

Jag använder disken för lagring till en mediaserver som jag använder på hemnätverket. Så sker en del överföring både till och från disken på daglig basis. Men har egentligen inget behov av att koppla in den i andra datorer, så skulle absolut kunna vara formaterad på ett sätt som är optimalt med Ubuntu.

När jag kör sudo fdisk -l så får jag följande:
...
GPT PMBR size mismatch (4294967294 != 27344764926) will be corrected by write.
Disk /dev/sda: 12.75 TiB, 14000519642624 bytes, 27344764927 sectors
Disk model: Expansion Desk
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 466BCCBC-9B38-4BF0-83D2-7BBD5083871A

Device Start End Sectors Size Type
/dev/sda1 40 409639 409600 200M EFI System
/dev/sda2 411648 27344762879 27344351232 12.8T Microsoft basic data

Tänkte på "GPT PMBR size mismatch". Vad betyder detta och är det ett problem?

Stort tack för utförliga svar!

Låter som bästa att göra just nu är att helt enkelt formatera om disken till ext4. När jag formaterade till exFAT så gjorde jag inga egna inställningar, så antar att formateringen i sin helhet blev sådär by default. Finns det något exakt kommando som jag bör köra för att få disken att bli formaterad/partionerad på det bästa sättet enligt ovan? Och menar ni då att detta skulle göra att disken inte matar ut sig själv?

Dom tips jag fått tidigare har varit att försöka avaktivera sleep-/power saving-funktionaliteten på disken. Då detta inte verkade gå att göra på något vettigt sätt via mjukvara så fick jag rådet att tejpa för en av SATA-pinnarna med eltejp. Detta gav ingen märkbar effekt på faktumet att disken matar ut sig själv, då den några timmar senare just matade ut sig själv.

Det andra tipset var som sagt att svartlista UAS, vilket gav mycket tydligare effekt då disken fram tills att jag skapade den här tråden var på och fungerade i flera veckor utan att mata ut sig själv. Innan dess har den matat ut sig själv efter några timmar i värsta fall, men som bäst har den kanske varit mountad i 1-2 dagar innan den matat ut sig själv.

Jag upplevde dock inga såna här problem med disken till en början när jag nyss hade köpt den. Problemen började uppstå efter några månaders användning. Och sedan den gången har den fortsatt att mata ut sig själv med jämna mellanrum.

Det jag får när jag kör det är:
smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.4.0-105-generic] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org

Read Device Identity failed: scsi error unsupported field in scsi command

A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options.

Om jag gör det på den exakta partitionen som gäller, alltså sda1, så får jag:
=== START OF INFORMATION SECTION ===
Vendor: Seagate
Product: Expansion Desk
Revision: 0915
Compliance: SPC-4
User Capacity: 14,000,519,642,624 bytes [14.0 TB]
Logical block size: 512 bytes
Physical block size: 4096 bytes
LU is fully provisioned
Logical Unit id: 0x3e414142534d5a54
Serial number: NAABSMZT
Device type: disk
Local Time is: Mon Mar 28 10:41:00 2022 CEST
SMART support is: Unavailable - device lacks SMART capability.

=== START OF READ SMART DATA SECTION ===
Current Drive Temperature: 0 C
Drive Trip Temperature: 0 C

Error Counter logging not supported

No Self-tests have been logged

Enligt den här tråden så står det:

"...all Seagate enclosures have ATA passthrough disabled when using UAS (​https://github.com/torvalds/linux/commit/7fee72d5e8f1e7b8d8212e28291b1a0243ecf2f1). So, smartctl does not work when UAS is enabled."

Disken mountas dock inte ens längre när jag svartlistar UAS. Jag kunde göra detta förut som sagt, och det verkade göra att disken också tuffade på längre tid utan att mata ut sig själv, men sedan den senaste auto-utmatningen så verkar den inte längre gilla när jag svartlistar UAS.

Tack!

Men jag tror att jag lyckades. /dev/sda är nu formaterad enligt ext4 och det finns inga andra partitioner. Har faktiskt snurrat på nu i lite mer än ett dygn och har inte matat ut sig själv än. Återkommer om det händer igen. Är det några loggar som skulle vara extra intressanta i fallet att den matar ut sig igen?

Återupplivar denna tråd då jag har fortsatta problem med disken.

Sen sist så har jag formaterat om hårddisken till ext4 efter rekommendation, då det skulle kunna funka bättre med Linux. Hade den formaterad i exFat tidigare. Jag har också numera disken i en QNAP TR-004. Använde tidigare själva originalchassit men har nu alltså plockat ut disken från detta och satt in i en "RAID-låda". Vet att det diskuterades att det kunde vara något med hårdvaran i chassit som jag använde tidigare, att själva USB-delen där kanske spökade, varför jag ville testa att använda något annat för att se om det gav någon effekt.

Men jag har fortsatt samma problem som tidigare. Disken verkar mata ut sig själv med jämna mellanrum. Senast idag hände det och jag körde dmsg -T för att se vad det gav för information. Kan se att EXT4-fs error och EXT4-fs warning förekommer några gånger, men skulle gärna behöva lite hjälp för att tyda vad dessa meddelanden betyder.

https://pastebin.com/7sMjQwSw

Rödmarkeringen blev av en slump när jag valde bash som syntax, så var inte meningen att markera det specifikt. Men jag förstår att det kanske är lite väl generell info för att kunna dra någon slutsats.

Problemet började när jag använde kabinettet som följde med disken, då det var en extern hårddisk. Jag tog sedan ut disken helt och hållet och har den nu i en QNAP TR-004 där anslutningen är USB-C. Så i och med det så har jag nu både nytt kabinett och ny kabel, men problemet återstår.

Värt att tillägga är också att innan testade att tejpa för "pinnen" i SATA-anslutningen som skulle göra att disken inte går i viloläge, om jag förstod det rätt. Jag svartlistade också Uas i samband med detta och upplevde då att den fungerade bättre ett tag då den inte matade ut sig på flera veckor. Men till slut hände det igen och disken upptäcktes inte av systemet när jag startade om datorn, varför jag tog bort svartlistningen av Uas och den blev upptäckt igen. Jag tog dock bort tejpen när jag bytte kabinett och har fortsatt inte svartlistat Uas.

Datorn jag använder är en NUC. Kan ju absolut hända att det är dåliga kontakter eller dålig kabel inne i datorn, men då den kommer färdigbyggd så känns det inte lika troligt som om jag själva hade byggt datorn. Men det kan ju säkert finnas en risk.

Finns det några andra loggar som skulle ge mer specifik information eller kan jag felsöka på annat sätt? Eller kan man bara dra slutsatsen att det är själva disken som är dålig redan nu?

Jag ser också att rad 106 säger:
usb 2-3: USB disconnect, device number 2

Innebär detta att disken matas ut innan skrivfelet uppstår, eller sker detta pågrund av skrivfelet? Jag tänkte bara spontant att det låter som att själva USB-anslutningen helt enkelt försvinner av någon anledning, att det som du säger trots allt skulle bero på en dålig kabel eller USB-komponent i datorn? Jag bara spekulerar fritt.

Yes, i och med att jag bytte kabinett till disken så använder jag numera USB-C, så det är helt ny anslutning i form av ny USB-port samt ny kabel. Kan ju absolut testa en annan kabel, men denna följde med kabinettet som är sprillans nytt. Har även testat att ansluta kabeln till olika USB-portar på NUC:en lite då och då, men det verkar inte göra någon skillnad.

Ska kolla USB/SATA-chip ikväll. Återkommer! QNAP TR-004 ska ju vara specifikt gjort för extern lagring till NAS, så vore ju riktigt surt om dom valt ett chip som inte är optimerat för långvarig användning.

Gällande att koppla in med SATA till dator: menar du då att koppla in och helt enkelt se om den matar ut sig själv efter ett tag eller ej?

Kanske värt att testa att koppla USB-C till USB-C till NUC:en istället? Jag använder USB-C till USB 2.0 som följde med kabinetten i nuläget.

Det kan inte vara att själva NUC:en går i sleep mode? Det borde jag kanske ha sett i dmsg-loggen i sådana fall?