5

I'm trying to recover a bad sector on my disk, and in doing so, need to write over the bad sector. Numerous sources on the web suggest using dd to do so, but doing so does not work:

$ sudo dd if=/dev/zero of=/dev/disk1 bs=512 count=1 seek=961575240
dd: /dev/disk1: Operation not permitted
$

I figured maybe there was some sort of check about doing this to a mounted filesystem, so I booted into single-user mode (which at least leaves is in read-only mode), but I still get the same error. Some additional messages about sandboxing are also displayed however.

Sandbox: dd(5) System Policy: deny(1) file-write-data /dev/disk1
Sandbox: dd(5) System Policy: deny(1) file-write-data /dev/disk1

Is there a way to allow dd out of the sandbox? I tried 

sudo sandbox-exec -p '(version 1) (allow default)' /bin/dd if=/dev/zero of=/dev/disk1 bs=512 count=1 seek=961575240

but that still gave the operation not permitted error.

This is on OS X 10.11 GM

Improve this question
1
  • Do you have anything mounted on /dev/disk1 (even if it is a different sector)? That sounds like it is a disk. You might want to try writing to the partition (with the appropriate offset) if the partition is not mounted. Never try to alter content of a mounted partition, even if it is read-only. Kernels might not like it (so you may have system instability). Note: a lot of people, myself included, state that once a drive gives a single error, you should no longer trust the drive; such drives tend to go very bad more quickly than average drives that haven't had a first disk error. Backup!
    – TOOGAM
    Sep 26, 2015 at 6:17

3 Answers 3

Reset to default
4

I don't have a sacrificial computer to test this on, but I think you're running into the System Integrity Protection feature in El Capitan. Mostly, what SIP does is prevent you (even as root) from modifying system areas of the disk (/System, /sbin, /bin/ most of /usr, etc), messing with system processes, loading improperly signed kexts, etc. But in order to enforce that protection of system folders, it also prevents raw writes to the device the system volume is on. Yes, even if you're root (that's the point -- it's to limit the damage from malware that gets root access).

I think this limit won't apply in recovery mode. Hold Command-R as the computer starts, and it'll boot from a hidden emergency partition. Open Terminal (it's under the Utilities menu), and try the dd from there. dd might not exist on the recovery system (it's pretty minimal), but you can use /Volumes/Macintosh\ HD/bin/dd instead. You won't need sudo, you're already root.

If that doesn't work, try disabling SIP with csrutil disable, then rebooting normally (see Apple's doc on configuring SIP). Then, when you're done, I'd recommend reenabling it -- it's a useful security feature.

Improve this answer
2
  • Now you need a root for root. Genius /sarc
    – cde
    Sep 26, 2015 at 5:52
  • Thanks, that was quite informative. Recovery mode/terminal did get me a bit farther along in that I didn't get permission or sandbox errors, but it was still unhappy about the device being busy, so booted off of a SD card to do the dd.
    – Chris Eveland
    Sep 29, 2015 at 23:53
1

In my case I had to change my ”System Preferences > Security & Privacy > Full Disk Access > Terminal“ or iTerm2.

After I gave Full Disk Access to the Terminal or iTerm2 dds operations were permitted without changing SIP/root or +r... I tried that too ;-)

Improve this answer
2
  • Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center.
    – Community Bot
    Jan 8 at 23:10
  • This doesn't work at all on the system disk. Maybe it works on a non-system disk.
    – Nimrod
    Jan 25 at 9:01
0

Try using su.

On linux/unix you first have to set a password for the root user like:

sudo passwd root

Then you should have enough permission to do this.

Also check if all partitions are unmounted.

Type in mount and check which partitions are mounted.

Then:

sudo umount /dev/disk1sX

Instead of disk1sX write the correct partition.

Improve this answer
3
  • 1
    Running dd from root's shell (either booted fully or in single-user mode) gives the same result as 'sudo dd ...'. Even running with root permission, it seems to be in the sandbox.
    – Chris Eveland
    Sep 25, 2015 at 16:17
  • Have you tried sudo chown root:root /dev/disk1 ? Are you sure that you can write to /dev/disk1? It might be another issue...
    – xdevs23
    Sep 25, 2015 at 16:21
  • 3
    I had to use sudo diskutil unmountDisk /dev/diskNsX
    – Jacksonkr
    Jan 5, 2019 at 18:42

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.