Daily Blog #199: Adventures with Paladin and Write Blocked devices

Adventures with Paladin and Write Blocked devices - HECF Blog

Hello Reader,
        I'm going to interrupt the current series to document what I found today before I forget to. I've been using Linux on and off since 1995 and in that time I've never encountered this issue I did today. I did some searching on Google to resolve my issue and found a lot of confused answers and then figured it out. So for the benefit of those future confused examiners trying to figure out why their external drive is mounting read only as a write protected device in Linux here is the solution.


Paladin is fast becoming one of my favorite Linux Live CD distributions. When it comes to dealing with Mac systems specifically Paladin is my go to distribution as they tend to have better driver support for newer chip sets, such as the new MacBook Air. I was testing Paladin, a Thunderbolt external drive and a newer model MacMini to determine if the driver support was there as well as to test Thunderbolt support under Paladin.

When the MacMini first successfully booted off the Paladin Boot CD I went straight to see if the 3TB Seagate Backup Plus Thunderbolt drive I connected was recognized. I was happy to see that /dev/sdb was in fact my Thunderbolt drive and there appeared to be no issues. It was time to mount the Thunderbolt drive and do some transfer rate tests to see if its would be a better/faster acquisition option.


Once I attempted to mount the drive I received the following error from mount:
mount: block device /dev/sdb2 is write-protected, mounting read-only
Now I knew the block device was not actually write protected, and to make sure there was not some special Paladin feature I wasn't aware of in this distribution I attempted to mount the partition read/write within Paladin Toolkit. The Paladin Toolkit also failed to mount the volume read/write and instead falls back to a read only volume. So I here I am with a read only 3TB thunderbolt drive that I cannot write to and cannot test.

At this point I turned to Google and found a series of posts with people incorrectly blaming the lack of the newest ntfs-3g driver for the issue. The Thunderbolt drive I purchased was formatted hfs+ so I was quite certain that the ntfs-3g driver was not the issue and the hfs+ driver for Linux does not use fuse so I was sure that wasn't at issue either. Attempting to mount with -o force, remounting and other combinations of option all failed to override the read only behavior.


It was then that I saw someone mention fsck to check the disk and I remembered that many drive vendors clone an image on to disks in the factory. In this process many drive manufacturers leave the file system in a 'dirty' state meaning the last transaction was left unfinished in the journal for the filesystem. I wasn't used to the idea that a 'dirty' filesystem wouldn't mount with -o force passed in, the ntfs-3g driver for instance will mount a dirty ntfs filesystem with force or atleast used to. So I checked the status of the partition with fsck.hfsplus -q and sure enough it came back dirty.

I then ran fsck.hfsplus against /dev/sdb2, it fixed the state and then magically it mounted read/write again and I was able to finish my test and go to the client site to acquire a MacMini. I'm still not getting the transfer rates I expected, but it was still better than USB2. 

So if you find yourself with a partition that won't mount read/write in Linux, check the partition with fsck and you might find a dirty volume. This to me is a new behavior with the file system driver respecting the journal state of a volume, if anyone knows how long this has been true I'd be curious to know!

Also Read: Daily Blog #198

Post a Comment