3

We have a Redhat 7 machine. And the filesystem for device /dev/sdc is ext4.

When we perform:

mount -o rw,remount /grop/sdc

We get write protected error like:

/dev/sdc read-write, is write-protected 

in spite the /etc/fstab allow read and write and all sub folder under /grop/sdc have full write/read permissions:

/dev/sdc /grop/sdc ext4 defaults,noatime 0 0

Then we do

umount -l  /grop/sdc

and from df -h, we see that the disk is currently not mounted.

Then we perform

 mount /grop/sdc

but we get busy. :-(

So we do not have a choice and we perform a reboot.

And from history we do not see that someone limited the disk for read only by mount.

This is very strange, how the disk device became write protected?

In order to solve this we perform a full reboot, and now the disk is write/read as it should be.

What happens here, after reboot we check the dmesg and we see the following:

 EXT4-fs warning (device sdc): ext4_clear_journal_err:4698: Marking fs in need of filesystem check.
 EXT4-fs (sdc): warning: mounting fs with errors, running e2fsck is recommended
 EXT4-fs (sdc): recovery complete

can we say that during boot - e2fsck was performed ?

dmesg | grep sdc
[sdc] Disabling DIF Type 2 protection
[sdc] 15628053168 512-byte logical blocks: (8.00 TB/7.27 TiB)
[sdc] 4096-byte physical blocks
[sdc] Write Protect is off
[sdc] Mode Sense: d7 00 10 08
[sdc] Write cache: disabled, read cache: enabled, supports DPO and FUA
sdc: unknown partition table
[sdc] Attached SCSI disk
EXT4-fs warning (device sdc): ext4_clear_journal_err:4697: Filesystem error 
 recorded from previous mount: IO failure
EXT4-fs warning (device sdc): ext4_clear_journal_err:4698: Marking fs in 
need of filesystem check.
EXT4-fs (sdc): warning: mounting fs with errors, running e2fsck is recommended
 EXT4-fs (sdc): recovery complete
 EXT4-fs (sdc): mounted filesystem with ordered data mode. Opts: (null)
 EXT4-fs (sdc): error count since last fsck: 5
 EXT4-fs (sdc): initial error at time 1510277668: ext4_journal_check_start:56
 EXT4-fs (sdc): last error at time 1510496990: ext4_put_super:791
  • Very unclear question. What makes you think that "we get write protected"? Show the command (or output, or log) which shows that. Maybe use lsof(8). Show relevant lines in output of mount (without arguments). So you need to work more on your question, so edit your question to improve it more. – Basile Starynkevitch Nov 12 '17 at 10:46
  • Show also the permissions (with ls -ld or stat) of /grop/sdc before and after mount commands. – Basile Starynkevitch Nov 12 '17 at 10:52
  • Did you carefully read the documentation of mount(8), mount(2)? What file system are you using? What file -s /dev/sdc gives before any mount? Read e2fsck(8). Did you try (before the mount) some e2fsck -v /dev/sdc ? What did you got from that? – Basile Starynkevitch Nov 12 '17 at 10:55
  • hi Basile , not have the output because not save the screen memory but its for sure said that write protected ! when we run the remount , second the ds is ext4 , and under the folder ( by ls 0ld ) we have write permissions , – yael Nov 12 '17 at 11:05
  • If you don't edit your question you won't get valid answers. Youn don't need any screenshot, you can (and should) use commands and give their outputs (or lines in log files) in textual form (indented lines, four spaces before each of them). BTW Linux has directories, not folders (and terminology is important) – Basile Starynkevitch Nov 12 '17 at 11:06
3

It appears your filesystem has become corrupt somehow. Most filesystems switch to read-only mode once they encounter an error. Please perform the following commands in a terminal:

umount /dev/sdc
e2fsck /dev/sdc
mount /dev/sdc

If /dev/sdc is the harddisk which has your operating system on it, use a startup DVD or usb stick to boot from.

  • BTW, I recommend doing a backup. I'm guessing that the hard disk is dying. – Basile Starynkevitch Nov 12 '17 at 16:24
  • 1
    @BasileStarynkevitch The dmesg doesn't say block-level problems on the disk, although the OP gave us only a filtered one. – peterh Nov 12 '17 at 17:20
  • But failing e2fsck smells bad, especially when the failure repeats. And an extra backup is less costly than losing the content on an entire disk. – Basile Starynkevitch Nov 12 '17 at 17:21

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.