Min 24.04 kan inte hitta min stora externa härddisk, min gamla 20.04 kan

24.04 vadå? Windows? Linux?

Hör du att hårddisken börjar snurra upp sig när den får ström?

Min gissning: Var det 24.04 disken var kopplad i när strömmen klipptes? Misstänker det OS:et satt någon spärr mot den för att skydda filsystemet. Gissar att om du skulle försöka mounta den genom terminalen lär du få en god ledtråd om vad som felar och hur du löser det, kanske bara någon filsystem-check som behöver köras en gång.

Du är i forumdelen "Linux och överiga operativsystem". Så antagligen Linux. Dock finns det nog fler distar än Ubuntu som har version 24.04.

Jag kommer anta att det rör sig om Ubuntu oavsett så tror jag att förslaget nedan kommer fungera.

Som @Ibis var inne på så testa att montera den via terminalen.

Du måste lista ut vilken device det rör sig om. Alla device:er som Linux identifierat ligger som filer/kataloger under /dev . Du kan använda

lsblk -a --fs

för att lista ut vilken device det är genom att jämföra efter filsystem, storlek och label(misstänker att den använder NTFS som filsystem).

Du kan manuellt montera disken genom att använda

sudo mkdir /mnt/mydrive && sudo mount /dev/<device namn exempelvis sdb1> /mnt/mydrive

Kommandoraden skapar först en katalog "mydrive" under /mnt och sedan monterar disken till katalogen /mnt/mydrive, dvs du kommer hitta diskens innehåll i /mnt/mydrive om allt gick vägen annars kommer du få ett felmeddelande som kommer kunna leda oss vidare i felsökningen.

Missade den detaljen ser jag nu.

Står beskrivet i mitt tidigare inlägg

Vilken fysisk plats på moderkortet ligger den på? (M.2 / SATA / eSATA / USB A/C fram eller bak)
Inget annat som tar ovanligt lång tid?
Har den klonats? I så fall kan det vara att en annan disk / partition har samma UUID och monteras i filen /etc/fstab. Otroligt osannolikt, men det finns dom som vinner på lotto också. Samma katalog som namnet på namnet på disken brukar ge en extra siffra men kolla det också.

Programmet diskar (gnome-disk) visar alla dina fysiska diskar i GUI.

Att starta systemet från en Live-ISO och försöka se disken där kan hjälpa då du undviker några inställningar som eventuellt skulle dölja disken.

Bakgrunden här är antagligen att Ubuntu-versionerna kör olika drivers för NTFS som default. Paragon-drivern kom in i Linux någon gång runt 22.

Vad jag ser i tråden har filsystemet över huvud taget inte nämnts, så jag kan förstås ha fel. Och jag orkar inte engagera mig i Windows-relaterade saker för att efterforska några detaljer. Men man kan gissa att det finns en lösning som går ut på att i alla fall temporärt byta till den gamla FUSE ntfs-3g-drivern. Eller kanske köra chkdsk i Windows.

Nu blir jag nyfiken, varifrån fick du NTFS ifrån?
Min initiala gissning var nämligen EXT4 (som Ubuntu använder).

@Krassegrand , du får förtydliga så inte fler missförstånd uppstår. .)

Ja, kan vara värt att förtydliga filsystemet. Finns dock (enligt mig) många goda skäl för att använda NTFS eller rentav ExFAT på externa diskar, om dessa ska flyttas mellan datorer eller operativsystem. Kör Ext4 på en SSD ansluten till Raspberry Pi, inte alltid helt enkelt att få alla filrättigheter osv korrekt när jag sedan kopplar in den i MacOS (via Paragons extFS), ändrar lite grejor, och så tillbaks till Raspberry Pi igen.

Nu är det lite märkligt inklistrat men om jag tolkar det rätt så verkar `/dev/sda2` ha datan. I sådana fall kör du `mount /dev/sda2 <katalogen som du vill montera till>`

Du har väl redan räddat undan datat till en annan drive när du körde med windows eller ubuntu 20.04 innan du börja experimentera runt med disken med ubuntu 24.04 väl!?.

När det gäller data så så fins inget som heter 'hoppas' eller 'riskera' - man ser först till att det inte sker med tex backupper av datat på annan oberoende media innan man börja laja runt på en uppenbart påverkad/skadad filsystem.

NTFS är inget man skall ha som arkiv-filsystem - det är för vekt och bräckligt som tex. att man får strul efter att man råkat stänga av strömmen medans disken arbetar eller glapp på USB-sladden etc.

NTFS kan samla på sig märkliga fel utan att det upptäcks över tiden och när det blir påverkande fel som kanske ger avalanche-effekt på mer data helt plötsligt och det kan bli mycket krångligt att rädda ut datat felfritt. Ett av problemet med NTFS är att det fins inga checksummor någonstans i vare sig metadata eller vanlig data och så länge felen inte pekar utanför olika systemgränser så är det inget inom NTFS som märker det.

Använd ext4 eller hellre BTRFS för arkivhanteringen av data på externa USB-diskar och använd bara ExFAT/NTFS för att flytta data mellan olika OS när man inte vill strula med olika rättigheter och då bara med kopian av datat, inte orginalet.

Men det är alltså så att den funkar i Windows? Då är det nog bäst att 1) kopiera de viktiga(ste) filerna från den till en annan disk och 2) köra Windows felkontroll, antingen från Windows utforskare eller kommandotolken (man får lite fler val där).

Min erfarenhet är att Linux-varianter är lite försiktigare med att försöka fixa NTFS-fel, att Windows är lite modigare - men också kan ta i lite väl häftigt. En extra säkerhetskopia är aldrig fel, beroende på hur värdefullt man tycker innehållet är. Börjar det strula med en hårddisk måste man förutsätta att den är extra känslig för fel.

Har inte koll på just lucky backup men dessa brukar ha sina egna strukturer (repositorium) som inte ser ut som du är van vid.

hardcore users använder 'rsync' så fort det gäller att få två mappar eller diskar att bli lika.

ett typisk kommando i en terminal är 'rsync -avHP -i -i mapp/disk/att/kopiera/i/från map/disk/att/kopiera/till'

'-i -i' är för att man skall lite extra information medans det kopierar
'-s' kan man lägga till om man har typiska vm-images då det packas som sparsefiler (dvs. alla sektorer fyllda med '0' inom filen tar inte upp fysisk diskplats, bara bokförs i metadatat och de tomma sektorerna återgenereras senare vid läsning)

är man osäker i kommandot fungerar så provar man --dry-run som extra argument - dvs:

'rsync -avsHP -i -i --dry-run mapp/disk/att/kopiera/i/från map/disk/att/kopiera/till'

då gör den en torrkörning utan att göra något med filerna för att se att det ramla igenom på önskat sätt - speciellt om man har '--delete' och '--remove-source-files' med som argument i kommandoraden.

skriver man ls -lash så ser man i fillistans första kolumn i hur mycket filen tar i verklig diskplats - inte storleken den utger sig för.

på de nya disken skulle jag köra BTRFS av flera skäl:

1. du kan få komprimerande mappar, det kan du inte få i ext4

Man kan göra en mapp där allt som läggs i mappen komprimeras automatiskt genom att på mappen köra 'chattr +c mappnamn' och efter detta så alla filer som läggs i mappen, dess undermappar etc så komprimeras filerna automagiskt och utan att du ser det - det är multicore-kompression så det hinner lätt med marginal snurrdiskens skrivhastighet.

2. du kan göra kopia av befintliga subvolymer som är exakt likadana med snapshot utan att det tar extra plats och sedan kan modifieras individuellt eller kan sättas skrivskyddade i samband när snapshot görs - det är bara förändringar som görs som tar ny plats. en snapshot tar bara några få sekunder att göra även om du har 10 TB med data och en miljon filer i subvolymen.

3. allt är checksummat (det är default) och när man skapar volymen så är också metadatat också alltid i dubbel upplaga på lika ställen av disken. man kan koppla till diskar senare för att öka volymen logiskt (och även välja olika RAID-moder) och då kommer det automatisk att sprida metadatat till kopia på var sin fysisk disk.

Man skall ha väldigt rejäl dåligt dag om BTRFS inte repar sig efter fula urdrag och strömavbrott mitt under full skrivande - läs, det har aldrig hänt för mig hittills att BTRFS inte är accessbar efter sådan händelse - dock kan det ta lite tid efter en sådan händelse så man bör inte bli nervös om det kan ta minuter innan disken blir åtkomlig.