0

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 
  • @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. – Steve Lorimer Apr 2 at 21:47
2
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
  • lsblk shows the device is RO – sourcejedi Apr 2 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 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? – Steve Lorimer Apr 2 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".

  • 1
    lsblk shows that there is an ext4 filesystem on the disk. There is only 1 partition, so /dev/sdc should be sufficient – Steve Lorimer Apr 2 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 at 3:53
  • 2
    @0xSheepdog: Yes, ext4 can do that. In fact, I think any Linux filesystem driver can do that. – telcoM Apr 2 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] – Steve Lorimer Apr 2 at 21:48
  • @telcoM Thought so but wasn't certain. Thanks! – 0xSheepdog Apr 3 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.