Q:

Unable to check a mdadm RAID1 array, says the file system's read only?

I recently migrated a RAID1 from a CentOS 5 system to a CentOS 6 system and ever since when I attempt to perform a check I get the following:
$ echo 'check' > /sys/block/md127/md/sync_action
-bash: /sys/block/md127/md/sync_action: Read-only file system

This actually shows up from a CRON too, specifically, /etc/cron.d/raid-check. this is included in the mdadm RPM:
$ rpm -ql mdadm | head -5
/etc/cron.d/raid-check
/etc/rc.d/init.d/mdmonitor
/etc/sysconfig/raid-check
/lib/udev/rules.d/63-md-raid-arrays.rules
/lib/udev/rules.d/65-md-incremental.rules

Here I'm running the same command that's used by the CRON:
$ raid-check
/usr/sbin/raid-check: line 96: /sys/block/md127/md/sync_action: Read-only file system

This typically runs once a week and sends an email which is what originally alerted me to the issue. But at any rate I'm at a loss why this RAID seems to be unable to be checked.
The RAID seems fine on inspection though.
$ cat /proc/mdstat 
Personalities : [raid1] 
md127 : active raid1 sda1[0] sdb1[1]
      976759936 blocks [2/2] [UU]

unused devices: <none>

I point this out only because while googling I found this thread regarding a bug in mdadm but this was for a older version of mdadm.

Debian Bug report logs - #380746
checkarray: E: /sys/block/md_d1/md/sync_action not writeable.

Version info
$ lsb_release -d
Description:    CentOS release 6.6 (Final)

$ rpm -q mdadm
mdadm-3.3-6.el6_6.1.x86_64

$ mdadm --version
mdadm - v3.3 - 3rd September 2013

A:

Thanks to @frostschutz's comment the issue appears to be due to /sys being mounted as readonly (ro). This was evident through this command:
$ cat /proc/mounts |grep sys
sysfs /sys sysfs ro,seclabel,relatime 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0

This appears to be an issue with docker. I found this issue titled: sysfs goes into readonly mode with host networking #7101. A workaround to the issue is to remount /sys read-write (rw) like so:
$ mount -o remount,rw /sys

Looking through the issues in docker's issue tracker it's unclear to me whether this is intentionally being left this way or not. The workaround is good enough for me for the time being but this seems like a bug to me.

