Permission denied when data scrubbing a RAID, even when run as root.

99lives · 2017-12-01 08:38:57

I have a RAID 0 in my machine, which was set up as per the instructions in the wiki. The wiki said that regular data scrubbing should be performed, but when I input the given command in the wiki, I get the following:

sudo echo check > /sys/block/md127/md/sync_action
-bash: /sys/block/md127/md/sync_action: Permission denied

Even though I am using sudo, I still get denied. Even when I use 'su' then type the command it doesn't work. Even directly logging in as root from a tty, permission is denied.

I've looked all over, and haven't found a solution. Any help would be appreciated, cheers.

Edit: I've just thought that since my RAID setup is a RAID 0, which has no duplication across disks, that scrubbing might not actually be relevant to it. Does scrubbing mean finding data that *should* be duplicate but isn't? If that's the case, then scrubbing isn't relevant to a RAID 0, and a note should be put in the wiki for this use case. Thoughts?

Last edited by 99lives (2017-12-01 08:59:58)

frostschutz · 2017-12-01 09:30:41

You're using sudo for the echo. So 'echo check' runs with root permission. But the redirection > still is regular user permissions.

You need to run a program that writes to a file as sudo.

echo check | sudo tee /sys/block/md127/md/sync_action
echo check | sudo dd of=/sys/block/md127/md/sync_action

or just run check with mdadm directly (should be the best option in this particular case)

sudo mdadm --action=check /dev/md127

99lives · 2017-12-04 08:33:26

I figured that the redirection may have had something to do with it but, these commands still aren't working.

The first two commands both had permission denied, and the second one failed with a "No such file or directory" error.

seth · 2017-12-04 09:07:19

stat /sys/block/md127/md/sync_action
mount | grep sysfs

frostschutz · 2017-12-04 10:16:55

Well, what's the device name of your RAID?

/dev/md127+ is for auto assembled RAIDs not specified in mdadm.conf. This number might also change, e.g. /dev/md0 in your real system, but /dev/md127 on a livecd.

You have to check `cat /proc/mdstat`, `lsblk`, and check UUIDs to know which is which.

Last edited by frostschutz (2017-12-04 10:18:41)

99lives · 2017-12-06 05:33:38

My device name actually is /dev/md127.
And heres the output of those two commands:

cat /proc/mdstat
Personalities : [raid0]
md127 : active raid0 sda1[0] sdb1[1]
1953259520 blocks super 1.2 512k chunks

unused devices: <none>

lsblk
sda 8:0 0 931.5G 0 disk
└─sda1 8:1 0 931.5G 0 part
└─md127 9:127 0 1.8T 0 raid0 /media
sdb 8:16 0 931.5G 0 disk
└─sdb1 8:17 0 931.5G 0 part
└─md127 9:127 0 1.8T 0 raid0 /media
(other devices omitted)

I followed the wiki setting up this RAID as part of my initial Arch installation, creating it from the livecd, but it was some time ago so I don't remember exactly what I did.
But checking mdadm.conf, there are no settings in it that specify my RAID, and reading the wiki again, I should have my devices in mdadm.conf.

Seems like I messed my RAID setup somehow, and it would probably be safer for me to rebuild it. Though I've never had any issues with the data in my RAID, including through reboots, so its weird that it would be seen as being on a livecd.

Strange. But I've got my data backed up, so I'll just rebuild the RAID again.

Thanks for helping me realise this, and thanks for your insight

Last edited by 99lives (2017-12-06 05:35:10)

Arch Linux

#1 2017-12-01 08:38:57

Permission denied when data scrubbing a RAID, even when run as root.

#2 2017-12-01 09:30:41

Re: Permission denied when data scrubbing a RAID, even when run as root.

#3 2017-12-04 08:33:26

Re: Permission denied when data scrubbing a RAID, even when run as root.

#4 2017-12-04 09:07:19

Re: Permission denied when data scrubbing a RAID, even when run as root.

#5 2017-12-04 10:16:55

Re: Permission denied when data scrubbing a RAID, even when run as root.

#6 2017-12-06 05:33:38

Re: Permission denied when data scrubbing a RAID, even when run as root.

Board footer