Error running authopen to gain access to disk device 'dev/rdisk2' #270
Comments
|
I'm getting what looks like the original error. The dialog says, "Error running authopen to gain access to disk device '/dev/rdisk21'" But Pi Imager had access to removable drives. This persisted for a while, until I mounted another thumbdrive and then ejected it and remounted the original... then Imager could inexplicably write to the SD card. Seems like an Apple bug. |
|
I am getting this as well. Problem occured after I use 'Erase' on my brand new SD Card. |
|
So I didnt have much luck in unmounting APFS container using Disk Utility. In fact, there was no additional APFS container for me other than the system one that is used by MacBook Pro for boot. But this led me to a clue: Disk Utility was hanging up while I was having my SD Card plugged in. So I tried this: After printing the above, the command did NOT exist, instead it just hang there and I would have to kill it with Ctrl-C. After several more attempts, I decided to just leave the command running... and it exist after more than 1 hour. I think this has something to do with the way rpi-imager Hope this help who ever encountering this next. |
After telling Imager to FAT32 format (erase) a card. Running
Actually, on the MacOS platform we outsource FAT32 formatting to diskutil (We just call
Some questions:
|
...
These are helpful. Thanks for the pointer. I was used to the old day where reformatting a disk is always a good practice before creating a boot disk.
I have 3 SD cards and this issue happens on 2 of them with 1 being quite persistent. I have only start hacking on this and encountered it last night... I might need to try it again sometimes to determine that it consistently reproducible.
I don't have one at hand right now.
Yes I do but I doubt that this is the case. |
Do note that an "empty" SD card also has files inside. This is what a SD card that has just been formatted under Mac OS X, and shows empty there, looks like when viewed under Linux: In this example it are all Mac OS X system files, used for things like the "file search" feature in Mac OS X. |
|
BTW if authopen fails with "Resource busy", you may also want to try if you can get If you run it normally -when the file system is mounted-, it should only show some mds system processes: After you selected RPI OS in Imager, pressed "write", and entered "yes" at the confirmation prompt, it should unmount the volume automatically, and nothing should show in lsof anymore: |
|
I'm having a similar issue on an Intel Mac with an external USB-C reader. I can write the image, but when it comes to remounting the FAT32 partition to write the config it tells me:
|
|
Closing as stale - no updates since '22. Not entirely clear that there's an issue with Raspberry Pi Imager in this report, it appears an external factor in the OS is holding the device open when Imager wants exclusive access. @maxnet has correctly identified there are a number of such entities that could do such a thing - none of which Imager is in a position to stop. If this is seen again, please raise a new issue. |
This is maybe a recursion of #99.
The security settings are set to allow Raspberry Pi Imager to access external volumes, or full access, but the message still happens.
Running in the console gives a more useful message:
Workaround: Opening Disk Utility and unmounting the APFS container that was on that SD card solved the problem.
The text was updated successfully, but these errors were encountered: