Nya erbjudanden i Komplett Geek Week

Hittar ingen mount point för extern hårddisk

Permalänk
Medlem

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?

Permalänk
Medlem

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.

Permalänk
Medlem

Har du kollat smart-data på disken så det inte är fel på den?

En möjlig tattar-lösning skulle vara att lägga en remount på disken med cron i valfritt tidsintervall. Ingen bra lösning. Helst skulle man vilja hitta felet...

Permalänk
Medlem

Vad har du för partitionstabell på disken?

Du ser info i programmet GParted menyn Visa -> Enhetsinfo. ("sudo apt install gparted i en terminal om det inte är installerat) programmet är grafiskt (därav första bokstaven är G).

dumpa gärna vad du ser även från lsblk och blkid. Dumpa gärna filen /etc/fstab också så det inte ligger någon konflikt där.

lsusb är inte så intressant då den endast visar diskens "usb-uttag".

Vad används disken till? Är den bara intressant för Ubuntu så är det bättre att använda en GPT-tabell med en EXT4 partition.

Permalänk
Medlem
Skrivet av Eazy:

Har du kollat smart-data på disken så det inte är fel på den?

En möjlig tattar-lösning skulle vara att lägga en remount på disken med cron i valfritt tidsintervall. Ingen bra lösning. Helst skulle man vilja hitta felet...

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

Skrivet av OldComputer:

Vad har du för partitionstabell på disken?

Du ser info i programmet GParted menyn Visa -> Enhetsinfo. ("sudo apt install gparted i en terminal om det inte är installerat) programmet är grafiskt (därav första bokstaven är G).

dumpa gärna vad du ser även från lsblk och blkid. Dumpa gärna filen /etc/fstab också så det inte ligger någon konflikt där.

lsusb är inte så intressant då den endast visar diskens "usb-uttag".

Vad används disken till? Är den bara intressant för Ubuntu så är det bättre att använda en GPT-tabell med en EXT4 partition.

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.

Permalänk
Medlem

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?

Permalänk
Medlem

Jag är rätt n00b på linux men fixade infon från en raid disk och då gjorde jag en mount point med mkdir komandot.
Har ingen aning om hur man löser error meddelandet dock.

Permalänk
Medlem
Skrivet av toge:

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

Låter rätt otroligt att den inte har smart, men visst, jag kan ha fel, det har jag ofta
Du kan ju pröva att installera "smartmontools" så vet du.

sedan:
sudo smartctl -a /dev/sda (eller /dev/sdb)

Permalänk
Medlem
Skrivet av toge:

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

Det jag ser här är att du har en boot-flagga för vardera av partitionerna. Något du bara ska ha på en partition.
Om disken inte är den du bootar från så ska du i praktiken inte ha någon flagga alls.
1 20.5kB 210MB 210MB fat32 EFI System Partition boot, esp
2 211MB 14.0TB 14.0TB msftdata

msftdata är helt onödigt att använda i ett linuxsystem och är avsett för microsoft filesystem data (FAT eller NTFS).

en korrekt partitionstabell här borde vara:
# --- start ----- slut -------- storlek --- filsystem --- flagga
1-- *0MB ---- 14.0TB --- 14.0TB ------ ext4 --------- [tom]
*Referens till tidigaste sektor (<1MB).

VARNING!
EN VÄLDIGT INTRESSANT GREJ ÄR ATT PARTITIONEN PÅ 14TB INTE HAR NÅGOT FILSYSTEM LISTAT

Detta kanske förklaras av fdisk.

Skrivet av toge:

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?

Meddelandet från fdisk är lite värre tyvärr. Det här innebär att partitionstabellen är skadad. I värsta fall för att något inte stämmer med diskens sektorer fysiskt eller att den gjort något fel vid en urkoppling. Eller har skadade sektorer som inte syns.

PMBR är Protective Master Boot Record vilket är den del av GPT som är avsedd att skydda disken från att användas i gamla system. som inte är kompatibla med GPT. Gränsen för storlek där är 2TB. Disken ser alltså ut som en MBR-disk på 2TB dit det inte går att ändra eller ta bort partitioner av misstag. Eller åtminstone inte vind för våg. Hur skyddande det här är i verkligheten har jag inte praktiserat själv, så svårt att säga hur det fungerar eller ser ut på ett gammat system.

Wikipedia - GUID Partition Table

Svårt att säga om fdisk kan reparera detta. Kan inträffa tre scenarion:

  1. Fdisk lyckas göra detta

  2. Fdisk lyckas "få bort varningen" men inget händer i praktiken

  3. Disken blir mer korrupt än den redan är

Med tanke på varningen i förra citatet så är mitt förslag är att du blåser disken fullständigt och börjar om från början. Enklast vore att smälla upp en EXT4 eller BTRFS partition över hela disken.

Permalänk
Medlem

Håller med om att det nog är bäst att köra över disken med nytt filsystem (och ny disklabel, köra wipefs direkt på disken borde rensa bort allt sådant), kan vara rätt värt med btrfs om den bara är för Linux då det kan detektera datafel. Att protective MBR är paj är förstås inte bra men GPT har till skillnad från MBR en extra kopia av viktig data, vet inte om den någonsin används automatiskt dock.
Smart på externa diskar kan vara lite kinkigt men inte fel att få igång det och köra ett test.

Permalänk
Medlem

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.

Permalänk
Medlem
Skrivet av Eazy:

Låter rätt otroligt att den inte har smart, men visst, jag kan ha fel, det har jag ofta
Du kan ju pröva att installera "smartmontools" så vet du.

sedan:
sudo smartctl -a /dev/sda (eller /dev/sdb)

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

Permalänk
Medlem

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.

Permalänk
Medlem

Du behöver köra detta på disken, sda, inte på på på partitionen sda1.

[b]Sedan måste du vara säker på att sda är rätt disk[./b]

Bråkande diskar brukar jag skiva över 1:a GB med dd.

Kommandot man dd berättar mer.

Bor du i Stockholm kan jag göra en sväng förbi lite senare idag eller ett zoom-möte (video på webben). Då är det lättare att hjälpa dig.

Skicka ett PM.

Permalänk
Medlem
Skrivet av OldComputer:

Du behöver köra detta på disken, sda, inte på på på partitionen sda1.

[b]Sedan måste du vara säker på att sda är rätt disk[./b]

Bråkande diskar brukar jag skiva över 1:a GB med dd.

Kommandot man dd berättar mer.

Bor du i Stockholm kan jag göra en sväng förbi lite senare idag eller ett zoom-möte (video på webben). Då är det lättare att hjälpa dig.

Skicka ett PM.

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?

Permalänk
Medlem

Å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

Permalänk
Medlem

titta på rad runt 107 - där börjar skrivfelen när ext4 skall uppdatera journalen

det du rödmarkerat är bara kräk av följdfel som inleddes med felen kring rad 107. - det ger lika lite information som de sista raderna när du får kompileringsfel när du kompilerar ett felaktigt skrivet C-program. - det är första felet man skall jaga...

har du kört disken direkt på SATA-bus (detta för att få viss koll om det är disken i sig som är problematisk)

nu verkar det som att du kör via USB och det kan vara allt ifrån USB/SATA-chiproblem i din externa kabinett - kabeln inte är fullgod (dålig USB-kabel ger inte CRC-fel i SMART) dåliga kontakter eller dålig kabel inne i din dator om den är stationär och ansluter vid fronten.

Permalänk
Medlem

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?

Permalänk
Medlem
Skrivet av xxargs:

titta på rad runt 107 - där börjar skrivfelen när ext4 skall uppdatera journalen

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.

Permalänk
Medlem
Skrivet av toge:

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.

Kan hända p.g.a. glapp USB-kabel. Prova med annan kabel om du inte redan gjort det.

Permalänk
Medlem
Skrivet av SAFA:

Kan hända p.g.a. glapp USB-kabel. Prova med annan kabel om du inte redan gjort det.

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.

Permalänk
Medlem
Skrivet av toge:

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.

Den missade jag faktiskt - och det är som du misstänker att det är grundorsaken till spyan av fel senare - även rad 107 är då en följdfel.

vet du vad det är för USB/SATA-chip i kabinettet (bör kunna ses i samband med inkoppling i dmesg) - är den jmicron så är de ökända att ha problem - ofta blir det bättre när UAS blacklistas eller vartfall felen blir med längre mellanrum...

Du bör också göra övningen att koppla in disken direkt med SATA till datorn och se om det är en möjlig grundkällan till problem - att göra via USB ger en extra länk av potentiellt trubbel och svårare att pin point:a ut det egentliga felet.

Permalänk
Medlem
Skrivet av xxargs:

Den missade jag faktiskt - och det är som du misstänker att det är grundorsaken till spyan av fel senare - även rad 107 är då en följdfel.

vet du vad det är för USB/SATA-chip i kabinettet (bör kunna ses i samband med inkoppling i dmesg) - är den jmicron så är de ökända att ha problem - ofta blir det bättre när UAS blacklistas eller vartfall felen blir med längre mellanrum...

Du bör också göra övningen att koppla in disken direkt med SATA till datorn och se om det är en möjlig grundkällan till problem - att göra via USB ger en extra länk av potentiellt trubbel och svårare att pin point:a ut det egentliga felet.

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.

Permalänk
Medlem

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?

Permalänk
Medlem
Skrivet av toge:

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.

Mot just QSNAP-maskiner/NAS ja - QSNAP har säkert dubbelkollat att sina egna delar lirar ihop med varandra men det är ingen garanti att det fungerar problemfritt mot andra plattformar.

Citat:

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?

Precis - detta för att se att det inte är disken själv som i slutändan är roten till det onda och därmed utesluta denna om det inte visar problem. om möjligt bör du kolla med ytterligare snurrdisk och se om problemet är lika som innan eller blivit annorlunda med ny disk.

Vid felsökning måste man bryta upp kedjan i de olika överföringarna till separata block med så få och översiktliga funktioner som möjligt - det är ett elände när att hänger ihop i en kedja och någon led inte sköter sig som det skall.

Permalänk
Medlem

Tack för svar!

Jag har nu haft disken ansluten med USB-C i ett par dagar utan att den har matat ut sig. Ville testa att ansluta till Thunderbolt-porten på NUC:en för att helt kringgå USB-portarna. Så det verkar lovande än så länge, även om jag inte vill ropa hej ännu.