Sudo Required To Successfully Run gphoto2 Command on Canon 5DS R from MacOS 14.1 and Newer via USB

[vepicurean]

I have discovered that to consistently run the standard gphoto2 commands I've been using for years on Macs with the Canon 5DS R cameras via usb, the Macs running above MacOS 14.1 and newer need to always use "sudo gphoto2" to avoid running into the dreaded "can not claim usb". In this case the can not claim usb is caused by a kernel driver that won't detach. The legacy camera work around that Apple giveth back a while away with 14.1, they quickly decided to take away ( see here ) The only way I can get it to detach is to turn the camera off and back on.

Others have been discussing this sudo issue on MacOS 14.1 and above with gphoto2 for a while, and I see work arounds, I am likely just missing it, but I've looked through the discussions, but I don't see if there is a permanent development within gphoto2 so that sudo is not required with gphoto2 to consistently ( remote capture and download using --wait-event-and-download="FILEADDED" repeatedly, every 7 to 15 seconds) run a gphoto2 command on a Mac running MacOS 14.1 or newer?

In summary, to get MacOS and gphoto2 to work without sudo like it was prior to MacOS 14.1, is this developed into a recent version of gphoto2 intended to run on the latest versions of MacOS ( MacOS 15 was released back in September 2024. Seems to perform for standard applications just fine, I have not tried gphoto2 on it yet)?

That is the question I'm asking. These commands I've been using for a while so I don't think they are wrong. The underlying MacOS hardware and operating system are just not playing nice anymore with gphoto2 ( at least challenges with the MacOS software and hardware security environment via usb).

Use an Apple Silicon Mac with legacy camera support set to on ( I don't really see that the legacy camera support toggled on does anything to help) to replicate environment exactly - others report that the sudo requirement happens on Intel Macs as well when they went to MacOS 14.1 or newer . The Intel Macs won't be around/supported much longer, so I don't think those Macs and gphoto2 are worth worrying about much longer. The ARM CPU/APU based Macs and gphoto2 should probably be the priority.

I'm using several Canon 5DS R at latest firmware with Macs running ARM based CPU/APU on MacOS 14.7 ( processing power and hardware setup is not the issue. Top of the line everything. All the cameras and computer hardware works perfectly independently).

Note it is important which physical Thunderbolt ports you use when you have multiple cameras ( especially the same model of camera) connected to the same Mac - the usb port numbers have to be very distinct for gphoto2 to tell them apart. That has been the case for a while. Nothing to do with this sudo issue though).

Command is as follows:

gphoto2 --port usb: xxy,yyx --set-config eosautofocusdrive="1" --filename somefilename.%C --set-config eosremoterelease="Immediate" --set-config eosremoterelease="Release Full" --wait-event-and-download="FILEADDED"

Note: from my observations, --set-config eaosautofocusdive="1" does not seem to work, at least with the 5DS Rs. It tends to lead to the cameras locking up. Remove it and this command below works just fine provided the usb port is not claimed by ptpcamerad ( an internal Apple MacOS process that is very hard to disable or remove) ahead of gphoto2

gphoto2 --port usb: xxy,yyx --filename somefilename.%C --set-config eosremoterelease="Immediate" --set-config eosremoterelease="Release Full" --wait-event-and-download="FILEADDED"

Even with the standard --capture-image-and-download on the Canon 5DS R with MacOS 14.1 or newer, I have to use sudo before the gphoto2 command to get the gphoto2 command to run and override the usb port claimed roadblock.

I use another version of the command where I've already focused the cameras and don't need to use the --set-config eosautofocusdrive="1" - Note: Make sure the lens is set to auto. Make sure the camera itself is set to either AI servo or Oneshot focus. Don't use any other AI driven focus method.

**Note - I was getting an error unknown during the file download of the image file to the Mac. I realized that I no longer see the "FILEADDED" message in the PTP messaging like I used to. When I switch to "CAPTURECOMPLETE" on the wait-event-and-download, the error unknown went away. Using "FILEADDED" was just faster to complete the process, so I could get faster access back to the command line prompt on the Mac. Also, you don't get the error unknown on the file download with --capture-image-and-download. I just don't like using --capture-image-and-download as it causes a focus to occur when I don't need it. Less control over when to focus and when not to focus ( unless I'm mistaken). That is why I've always like the Canon EOS platform ( especially vs Sony) and gphoto2 with Mac for programmatic photography because of the finer control over the focusing and shutter.

***Note: The users prefer Mac over Linux ( which is not surprising). But that means there are some challenges for gphoto2 as Apple does things their way and the peripheral equipment maker vendors have to fall in line. I run into it all the time. I've seen these MacOS security and operating system interface issues between Apple and the peripheral equipment makers at times never get resolved over many years - which is unfortunate. QNAP storage devices and MacOS poor stability over Thunderbolt is a case in point. Both companies acknowledge the issue, but it has never been resolved. Had to stop using QNAP.

I hope these notes help.

gphoto2 2.5.28 clang, popt(m), exif, no cdk, no aa, jpeg, readline

libgphoto2 2.5.31 standard camlibs, clang, no ltdl, EXIF

libgphoto2_port 0.12.2 iolibs: disk ptpip serial usb1, clang, no ltdl, EXIF, USB, serial without locking

[vepicurean]

Some more information on why running gphoto2 with sudo causes problems for programmatic control of the cameras ( correct me if I'm missing something here).

I finally figured out that for some reason when using sudo or running gphoto2 commands with top level su ( to get around the below mention usb device claimed), every command executed with the right usb ID, causes the usb ID to toggle ( change) back and forth. For example, when running as su, usb:002,002 changes to usb:002,003 - but when you run the next command using usb:002,003, it toggles back to usb:002,002. The program kept telling me usb not valid, and then I finally realized what was going on.

This behaviour does not occur when trying to run the same commands as an admin user or standard user on MacOS, but instead you get the dreaded usb device claimed (I/O error), which in this caused by a kernel driver that won't detach from the previous command. But Apple's attempt to help it's customers out with the legacy override did not help me with this situation ( Apple decided it was not their concern)...

[vepicurean]

I see now... gphoto2 users have been discussing how to deal with ptpcamera blocking acccess to the cameras via usb on the latest versions of MacOS here. Seems the camera vendors ran into the same issues and had to build their own extensions to deal with ptpcamera ( and ptpcamerad) on the latest versions of MacOS.

Here's a summary, based on several forum discussions on two options to address the situation with ptpcamera on MacOS ( note, the workaround I had to do to operate without using sudo, was quite extensive - not something I personally would recommended on your Mac. And it's probably only temporary and will run into the same issue again with something Apple does in the future).

Potential Long Term Solutions ( unfortunately have to involve working with Apple under their security rules):

For gphoto2 to achieve seamless integration with macOS, similar to proprietary software, collaboration with Apple would be essential. This collaboration could involve:

Developing a Dedicated Driver or Extension: Creating a macOS-specific driver or system extension that allows gphoto2 to communicate directly with cameras without interference from PTPCamera ( or ptpcamerad, which is obviously used by Apple for more than just Preview. I ran an experiment and ptpcamerad was also used/started by Adobe Bridge).

Leveraging Apple's APIs: Utilizing macOS's Image Capture Core framework or other relevant APIs to manage camera connections more effectively.

Implementing such solutions would require significant development effort and cooperation with Apple's development guidelines and security frameworks.

Conclusion:

While gphoto2 provides robust support for a wide range of cameras across multiple operating systems, its integration with macOS is hindered by system-level processes like PTPCamera. Addressing this issue would necessitate substantial development work and potential collaboration with Apple to create a more seamless experience for macOS users.

[ndim]

This now is the canonical place which describes what must be done for gphoto2 (and any libgphoto2 app at all) to seamlessly run on OSX.

Thank you very much for researching all this and writing it up.