Solved "DD operation not permitted" error

[Sivan!]

I have repeatedly tried this command:

# dd if=/dev/zero of=/dev/da0 bs=2048

dd: /dev/da0: Operation not permitted

Dolphin automatically mounts the USB. I could also work by mounting the device on a directory, could delete the files. The DD command is to format the device to transfer the install image. The DD command didn't work with the device mounted, nor unmounted. One of the fixes to this DD issue found in various forums is to run

# sysctl kern.geom.debugflags=0x10

kern.geom.debugflags: 0 -> 16

I have done that. The DD error is persistent. Mount works Umount returns errors:

# mount -v -t msdosfs /dev/da0 /media/usb

/dev/da0 on /media/usb (msdosfs, local, writes: sync 1 async 0, reads: sync 1848 async 0, fsid 7c00000032000000)

#
# cd /media/usb
# ls
# ls -l /media/usb

total 0

# mount

/dev/da0 on /media/usb (msdosfs, local)

# umount -v -t msdosfs /dev/da0 /media/usb

umount: unmount of /media/usb failed: Device busy
umount: unmount of /media/usb failed: Device busy

Please tell me if there is a way out.

 

[zirias@]

Do it as root? Being allowed to mount something doesn't mean you're also allowed to access the "raw" device (here /dev/da0).

Oh, and, do it in unmounted state.

 

[Sivan!]

# umount -v -t /dev/da0 /media/usb returns a blank line, but mount still shows

/dev/da0 on /media/usb (msdosfs, local)

# umount /media/usb [or] umount -t msdosfs /dev/da0 /mnt [or] umount -t msdosfs /dev/da0 /mnt

umount: unmount of /media/usb failed: Device busy

I could unmount it before, but still there was the dd operation not permitted error

 

[covacat]

try fstat /media/usb
also if you run a elevated securelevel you may not write to raw disk devs

 

[SirDice]

Do you have some sort of auto-mounting script running?

 

[Sivan!]

Do you have some sort of auto-mounting script running?

Yes I added an automount script because bsd wasn't detecting usbs. Added a line a few hours ago, after which dolphin automounted USB, even when unmounted, dolphin shows the USB.

Don't remember where I added, and don't remember what file I changed.Will try to locate what I changed.

Update SirDice : (still not sure) I think I added these lines earlier today to make usb detect

/boot/loader.conf

fuse_load="YES" cfumass_load="YES"

ps -ax | grep automount
88427 2 S+ 0:00.00 grep automount

gpart doesn't show USB, but camcontrol shows

doas camcontrol devlist

<TOSHIBA TransMemory 1.00> at scbus6 target 0 lun 0 (pass0,da0)

Also, as covacat says, kernel security level might also be a cause for this problem.

One of the errors that I see is da0: quirks=0x3<NO_SYNC_CACHE,NO_6_BYTE>

 

[smithi]

also if you run a elevated securelevel you may not write to raw disk devs

Yes, you beat me to it.

Sivan has kern.securelevel=3, despite having been advised by several people that it's necessary to understand the consequences of running that, especially on a desktop system with (apparently) no untrusted users and offering no outside services.

See https://forums.freebsd.org/threads/system-hardening-options-post-install.75476/page-2

If I thought it might help, I'd advise Sivan to read - at the very least - the section of security(7) titled SECURING THE KERNEL CORE, RAW DEVICES, AND FILE SYSTEMS to see why dd(1) to raw devices will not work with kern.securelevel > 1.

 

[Phishfry]

One of the errors that I see is da0: quirks=0x3<NO_SYNC_CACHE,NO_6_BYTE>

There is no error there. That is normal output.

 

[Sivan!]

Thank you smithi I have been a user with not much as an encrypted hard disk all along, but experienced too many strange problems that made it necessary to secure my computer to the extent that I could. There are issues, you are right, I have created these settings which are excessive, some of which have its own implications.

For now, I tried disabling all security settings, lowered kernel security to 0, ran hardening with all options unchecked, commented out the Security entries in all relevant conf files, rebooted, still DD does not work.

The issue has to do with some hints that I followed while trying to make BSD detect USB, after which USB automatically loads (and reloads even after unmounting, especially in the file manager dolphin, which probably keeps the USB automounted in the file manager, which also shows some errors while "safely removing USB". That process also does not work.

Thankyou Phishfry for pointing out that there is no error in the message related to quirks.

 

[Sivan!]

It appears more and more probable that the DD issue relates to USB auto-detect, and some bug in Dolphin file manager. Attaching a screenshot. (The file in the drive is the freebsd installer file, but the one copied from within a file manager in Chromebook (Crosh and chromebook recovery utility do not work in my Chromebook), not really really expected to work as a boot disk, and it didn't. Now this USB with this file needs to be wiped and the installer file rewritten.

smithi As this shows, the problem is not with Security levels being high, but on the contrary, occurred because I compromised it by enabling USB autoboot, which let dolphin take control of processes.

Update: After all this, the workaround was to boot in single user mode, and before KDE started, I tried the DD command, it worked, installed BSD in a very old server, extracted the ports tree. Solved.

 

[smithi]

smithi As this shows, the problem is not with Security levels being high, but on the contrary, occurred because I compromised it by enabling USB autoboot, which let dolphin take control of processes.

Well, not 'on the contrary' but 'as well', since without your compounding issue with automounting flash drives, you would then have still been blocked from using dd by having securelevel > 1.

Update: After all this, the workaround was to boot in single user mode, and before KDE started, I tried the DD command, it worked, installed BSD in a very old server, extracted the ports tree. Solved.

Glad to hear it. Single user is your only resort for problems caused by raised securelevel.

However since you'd earlier removed that securelevel setting and booted, all that was really needed was to run dd as root, as Zirias pointed out earlier.

File managers have their usefulness, but .iso or .img files cannot be copied to CD, DVD or flash drives as files, but only with (such as) dd(1).

Once you've done that, the automounter shouldn't even try mounting installer sticks, unless it also automatically mounts cd9660 filesystems as well as msdosfs ones?

 

[Sivan!]

However since you'd earlier removed that securelevel setting and booted, all that was really needed was to run dd as root, as Zirias pointed out earlier.

I (think) I tried as root even after bringing down Kernel Security level, the error remained unchanged.

File managers have their usefulness, but .iso or .img files cannot be copied to CD, DVD or flash drives as files, but only with (such as) dd(1).

It was in a moment of exhaustion, however pointless it seemed to copy it from file manager. As expected it didn't work

Once you've done that, the automounter shouldn't even try mounting installer sticks, unless it also automatically mounts cd9660 filesystems as well as msdosfs ones?

 

[dave01]

but experienced too many strange problems that made it necessary to secure my computer to the extent that I could.

If you want to be as secure as possible, it strikes me that having USB devices automount is a huge security hole and one of the first things to avoid when hardening a system.

 

[rpowell47]

I do not know if this will help others, but when one wants to carry out a "dd" procedure and receives the "Operation not Permitted," I found that it is the "GOEM" in the kernel. Thus, one can turn that off by this - SYNTAX
sysctl kern.goem.debugflags=0x10.

 

[bsduck]

"GOEM"

kern.goem.debugflags

You mean GEOM (like in geometry).

 

[rpowell47]

You mean GEOM (like in geometry).

You are correct! I have become kinda dyslexic in my many seasons of existence. Thanks for sharing.

 

[SirDice]

Note that you're not getting that error because GEOM is in the kernel. GEOM is the framework that's used by pretty much all disk related activities (ZFS is the exception to this rule, although it has been crowbarred into the GEOM framework).

What these debug flags allow you to do is to overwrite the disk you're currently booted from. In other words, it allows you to pull the rug from underneath the OS. Usually a bad idea.

Chapter 21. GEOM: Modular Disk Transformation Framework

In FreeBSD, the GEOM framework permits access and control to classes, such as Master Boot Records and BSD labels, through the use of providers, or the disk devices in /dev.

docs.freebsd.org