7

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
Improve this question
13
  • 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, 2017 at 10:46
  • Show also the permissions (with ls -ld or stat) of /grop/sdc before and after mount commands.
    – Basile Starynkevitch
    Nov 12, 2017 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, 2017 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, 2017 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, 2017 at 11:06

2 Answers 2

Reset to default
4

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.

Improve this answer
3
  • BTW, I recommend doing a backup. I'm guessing that the hard disk is dying.
    – Basile Starynkevitch
    Nov 12, 2017 at 16:24
  • 2
    @BasileStarynkevitch The dmesg doesn't say block-level problems on the disk, although the OP gave us only a filtered one.
    – peterh
    Nov 12, 2017 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, 2017 at 17:21
0

The reason for the error most likely is in the past. You should inspect system logs for messages related to the block device being used. Recent tools (e.g. dumpe2fs) can even display when an error had occurred, like this:

dumpe2fs 1.43.8 (1-Jan-2018)
Filesystem state: clean with errors
Errors behavior: Continue
FS Error count: 5
First error time: Mon Nov 1 00:22:11 2021
First error function: ext4_journal_check_start
First error line #: 60
First error inode #: 0
First error block #: 0
Last error time: Tue Nov 2 10:45:47 2021
Last error function: ext4_remount
Last error line #: 5175
Last error inode #: 0
Last error block #: 0

So that time stamps will give you a good interval where to look in the logs.

(For the case shown it was a loop mount of a sparse file and the underlying container filesystem was full)

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .