7

I have an SSD disk with an ext4 filesystem on it:

$ lsblk -f /dev/sdc 
NAME FSTYPE LABEL UUID                                 MOUNTPOINT
sdc  ext4         142b28fd-c886-4182-892d-67fdc34b522a 

I am attempting to mount it, but it is failing:

$ sudo mkdir /mnt/data
$ sudo mount /dev/sdc /mnt/data
mount: /mnt/data: cannot mount /dev/sdc read-only.
  • What does the error message mean?
  • How can I diagnose and fix the problem?

To add additional information pertinent to an answer below:

There is only one partition on the disk.

Here is the result of executing lsblk for the boot disk:

$ lsblk /dev/sda
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda       8:0    0   10G  0 disk 
├─sda1    8:1    0  9.9G  0 part /
├─sda14   8:14   0    4M  0 part 
└─sda15   8:15   0  106M  0 part /boot/efi

and here is the result of executing lsblk for the disk in question:

$ lsblk /dev/sdc
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sdc    8:32   0   2G  1 disk 
1
  • @sourcejedi it is a 2GB SSD disk, in so far as it is a Google cloud storage drive being attached (read-only) to a GCE VM. Apr 2, 2019 at 21:47

3 Answers 3

16

I had a similar problem with a USB thumb drive which was down to the ext4 journal recovery not working. dmesg confirmed this:

[1455125.992721] EXT4-fs (sdh1): INFO: recovery required on readonly filesystem
[1455125.992725] EXT4-fs (sdh1): write access unavailable, cannot proceed (try mounting with noload)

As it suggested, mounting with noload worked:

sudo mount -o ro,noload /dev/sdh1 /mnt/drive

I was then able to backup the content:

sudo rsync -av /mnt/drive /data/tmp/

and then use fdisk to delete and recreate the partition and then create a new filesystem with mkfs.ext4.

2
  • noload did it for me, thanks! Nov 13, 2021 at 1:22
  • OMG, thank you! I was able to mount the partition on a corrupted SD card and recover my files. Jan 11 at 4:32
3
mount: /mnt/data: cannot mount /dev/sdc read-only.

The problem might be that the ext4 filesystem on the device needs journal recovery, which is inherently a write operation. You might get more information by using the dmesg command after a mount attempt.

But I don't really see how your command

sudo mount /dev/sdc /mnt/data

was turned into a request for a read-only mount. Do you have an /etc/fstab line with specific options for this filesystem? Or do you have a custom script or alias named mount in root's environment?

Nevertheless, if the dmesg command does not provide any further insight, you might try an explicit request for a read-write mount:

sudo mount -o rw /dev/sdc /mnt/data

Or you might try running a filesystem check on it first:

sudo fsck.ext4 -C0 /dev/sdc
3
  • lsblk shows the device is RO
    – sourcejedi
    Apr 2, 2019 at 20:05
  • Oh, so the device itself is reporting it's read-only for some reason! I did not notice that. That might indicate a hardware problem of some sort: use sudo smartctl -HAf brief -l error /dev/sdc for a health check, and try sudo mount -o ro /dev/sdc /mnt/data for at least a chance to get your data out from a possibly-failing SSD.
    – telcoM
    Apr 2, 2019 at 20:52
  • @telcoM the device is read-only. It is, in fact, a google cloud disk attached to a vm. I have previously mounted it read/write and populated it with data, which I now want to attach to a different VM read-only. Previously this has succeeded (with a warning saying it's mounting read-only, as I didn't provide -ro), so it seems perhaps your suggestion of journal recovery is correct? Although I managed to "fix" the problem by unattaching, reattaching it read-write, and then reattaching it read-only again, and then it worked! Perhaps a gcloud bug? Apr 2, 2019 at 21:46
0

If I read that correctly, you are trying to mount a non-partition. It could be a simple typo in that you should be using "/dev/sda1" or "/dev/sda2" etc.. instead of just "sda"

If that's not the case, you'll need to use a partitioning tool such as fdisk or gdisk (or a GUI based tool such as gparted) to create a partition table and a partition. Then install a filesystem in that partition using "mkfs".

5
  • 1
    lsblk shows that there is an ext4 filesystem on the disk. There is only 1 partition, so /dev/sdc should be sufficient Apr 2, 2019 at 2:28
  • Hmmm, I am unfamiliar if ext4 can use a raw block device without a partition table. This is a common thing with LVM2 and PV, so it may be doable.
    – 0xSheepdog
    Apr 2, 2019 at 3:53
  • 2
    @0xSheepdog: Yes, ext4 can do that. In fact, I think any Linux filesystem driver can do that.
    – telcoM
    Apr 2, 2019 at 19:12
  • 1
    I just followed the instructions on [here])cloud.google.com/compute/docs/disks/add-persistent-disk). Format the disk. You can use any file format that you need, but the most simple method is to format the entire disk with a single ext4 file system and no partition table. If you resize the zonal persistent disk later, you can resize the file system without having to modify disk partitions. sudo mkfs.ext4 -m 0 -F -E lazy_itable_init=0,lazy_journal_init=0,discard /dev/[DEVICE_ID] Apr 2, 2019 at 21:48
  • @telcoM Thought so but wasn't certain. Thanks!
    – 0xSheepdog
    Apr 3, 2019 at 18:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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