Camera Scanning fails on macOS — ptpcamerad claims exclusive USB access, blocking direct-USB tethering

[ToddSch1979]

Environment:

macOS: 26.5.2 (Build 25F84)
NegPy: v0.51.1
Camera: Nikon D800
Hub: USB-C multiport hub (confirmed not hub-specific — same result direct-to-Mac)

Summary:

Camera Scanning shows the camera as connected (green "Camera (USB)" indicator) until Scan is clicked, at which point it immediately reverts to "Camera (in use)" with the message "Another app is using the camera — close Preview, Photos and Image Capture." No listed app is running.

Root cause (confirmed via Console.app):

error kernel NegPy@(null): AppleUSBHostUserClient::openGated: failed to open IOUSBHostInterface@0: provider is already opened for exclusive access by pid [X], ptpcamerad

ptpcamerad is a macOS system daemon that, since macOS 13+, auto-claims exclusive access to any USB interface it recognizes as PTP-class, including when no other app has manually invoked it. NegPy appears to open the USB interface directly (IOUSBHostInterface) rather than through Apple's ImageCaptureCore framework, so it loses this claim every time.

Steps to reproduce:

Connect Nikon D800 via USB.
Open NegPy, confirm camera shows connected.
Click Scan.
Camera immediately shows "in use"; Console.app shows the error above.

What we ruled out (extensive troubleshooting):

sudo killall ptpcamerad — process respawns within milliseconds (confirmed via PID tracking), reproducible even under a tight kill loop and repeated Scan retries over 30+ seconds.
sudo launchctl unload — fails with a SIP-related I/O error.
sudo launchctl disable — flag sets successfully but does not prevent on-demand relaunch (daemon is IOKit launch-on-demand, not simple launchd-managed).
Image Capture's "Connecting this camera opens: No application" setting — does not stop ptpcamerad itself from claiming the interface.
System Settings → Privacy & Security → Files and Folders / Full Disk Access — NegPy is not listed under either, and tccutil reset All negpy + relaunch produces no permission prompt, confirming NegPy does not currently request either permission.
Third-party mac-gphoto-enabler tool (patches Image Capture's device-matching database) — blocked by macOS file permission restrictions on /Library/Caches/.

Cross-confirmation this isn't NegPy-specific:
The identical error occurs in darktable's tethering module against the same camera/Mac:

failed to initialize Nikon DSC D800' on port usb:001,007', likely causes are: locked by another application, no access to devices etc

What does work:
Adobe Lightroom Classic connects and tethers reliably on the same hardware/OS, every time, with zero setup. This is consistent with Lightroom using Apple's ImageCaptureCore framework rather than direct USB access — this is also the approach libgphoto2 has an open RFC to implement (gphoto/libgphoto2#971), as this is a known, widespread issue affecting Canon (EOS Utility), Nikon, and other tethering tools on modern macOS.

Suggested fix:
Adopting ImageCaptureCore (or coordinating with ptpcamerad via the sanctioned API) rather than raw IOUSBHostInterface access would resolve this, matching Lightroom's approach. Happy to help test a build if useful.

[ToddSch1979]

Update: Found a workaround worth sharing — launching NegPy as root fixes this for me:

sudo /Applications/NegPy.app/Contents/MacOS/NegPy

With NegPy running as root, it successfully claims the USB device and Camera Scanning works reliably. This confirms the root cause: NegPy is losing the race against ptpcamerad for exclusive access to the USB interface on modern macOS, and running with elevated privileges is enough to win that race.

Running as root isn't something most users should have to do long-term, but it does point toward two possible fixes on your end:

Have NegPy request elevated USB access more gracefully (e.g. prompt for admin privileges specifically for the USB claim step), or
Longer-term, adopt Apple's ImageCaptureCore framework so NegPy coordinates with ptpcamerad instead of competing with it for the raw USB interface — this is the approach Lightroom Classic uses, and it connects with zero issues on the same hardware/OS here.

Happy to test a build or provide more logs if that would help track this down further.