I have a Pi 4 and want to mount my Samsung 860 EVO SSD. I am unable to accomplish this, but attaching a HDD (same adapter and usb port) work just fine.

Both the SSD and HDD were formatted in NTFS (using Windows) at the same time. Adding the HDD's UUID in the /etc/fstab file, running sudo mount -a i get a warning saying the filesystem was not closed on Windows, but it resolves and mounts immediately.

Doing the exact same with my SSD, it completely fails. RPi flags the same Windows filesystem error, but then hangs and freezes without mounting. Some other notable things is that often the blkid command doesn't show the SSD and only a reboot brings it back.

Manually mounting doesn't work either.

I have tried formatting the SSD as ntfs, exfat and ext4 trough the mkfs command, but i get the exact same results (without the windows file system warning this time ofcourse).

My only idea why this might be failing is because the 860 EVO is rated for 5v 1.2A (the HDD is only 0.7A). Reading the specs for the pi 4, it says that the USB ports should be able to deliver 1.2A and i have nothing else connected, so this seems like it should work.

Edit: dmesg dump when connecting the drive after booting: i also ran blkid again, its not listed

[   54.192995] usb 2-1: new SuperSpeed USB device number 2 using xhci_hcd
[   54.214297] usb 2-1: New USB device found, idVendor=152d, idProduct=0578, bcdDevice= 3.01
[   54.214308] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   54.214313] usb 2-1: Product: USB 3.0 Device
[   54.214318] usb 2-1: Manufacturer: USB 3.0 Device
[   54.214322] usb 2-1: SerialNumber: 000000004BA8
[   54.222862] scsi host0: uas
[   54.223976] scsi 0:0:0:0: Direct-Access     Samsung  SSD 860 EVO 500G 0301 PQ: 0 ANSI: 6
[   54.225922] sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/466 GiB)
[   54.225936] sd 0:0:0:0: [sda] 4096-byte physical blocks
[   54.226120] sd 0:0:0:0: [sda] Write Protect is off
[   54.226127] sd 0:0:0:0: [sda] Mode Sense: 53 00 00 08
[   54.226477] sd 0:0:0:0: [sda] Disabling FUA
[   54.226484] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   54.227117] sd 0:0:0:0: [sda] Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes)
[   54.231501]  sda: sda1 sda2
[   54.233318] sd 0:0:0:0: [sda] Attached SCSI disk
[   54.294954] sd 0:0:0:0: Attached scsi generic sg0 type 0
MadMagic@rb4:~ $ blkid
/dev/mmcblk0p1: LABEL_FATBOOT="boot" LABEL="boot" UUID="0F92-BECC" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="cf41a764-01"
/dev/mmcblk0p2: LABEL="rootfs" UUID="41c98998-6a08-4389-bf74-79c9efcf0739" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="cf41a764-02"

Update: Magically after waiting a few days it worked. all i did was format the SSD as NTFS again, i have no idea what exactly i did different, but it mounts just fine now.

  • Probably a problem with the closed source nature of NTFS, Only some types of "repair" are safe from Linux. Does it work if you format the SSD in ext4 or FAT32?
    – joan
    Feb 4, 2023 at 22:45
  • boot pi without SSD attached. attach SSD. wait a couple seconds. run dmesg. add the the last 20 or so lines of the result to the question Feb 4, 2023 at 23:02
  • @joan i already tried ext4. i tried fat32 now, i managed to get it to mount a single time, got excited and rebooted, doesnt work anymore.
    – MadMagic
    Feb 4, 2023 at 23:09
  • @JaromandaX i added the lines related to the connecting of the drive after changing to fat32 like joan suggested
    – MadMagic
    Feb 4, 2023 at 23:10
  • Not all USB->SATA devices are created equal - yours is a JMicron JMS578 ... I've had issues with jmicron adapters on raspberry pi in the past and have stopped using them - see this - where it states "JMicron devices are hit and miss, mostly miss" - truer words were never written Feb 4, 2023 at 23:23

1 Answer 1


This is not the answer to your question, but I thought it might be helpful to point out one obvious mistake you're making:

There are several tools that show block devices connected to a Linux host; e.g. blkid, ls -laF /dev/disk/by-uuid/, df -h, etc. But we must choose the correct tool for the job. It's a good habit to read the system manuals (e.g. man blkid) before using a tool whose output we will depend on for troubleshooting, or follow-on action. I learned this lesson after literally spending hours puzzling over why the output of blkid was different than lsblk --fs. Had I read man blkid first, I would have known immediately that:

It is recommended to use lsblk(8) command to get information about block devices, or lsblk --fs to get an overview of filesystems, or findmnt(8) to search in already mounted filesystems.
lsblk(8) provides more information, better control on output formatting, easy to use in scripts and it does not require root permissions to get actual information. blkid reads information directly from devices and for non-root users it returns cached unverified information. blkid is mostly designed for system services and to test libblkid functionality.

In other words, use sudo blkid, or don't use it at all! And in your case, I think that lsblk --fs is a better tool.

One other suggestion: An edit to your question that includes the contents of your /etc/fstab file might be useful.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.