iPhone does not remember trust settings

[radon-at-beeper]

When I connect my iPhone to my Linux computer with usbmuxd running, it asks whether my iPhone should trust the attached computer. However, this happens every single time I plug in the iPhone; it can't remember the trust settings. Is this expected behavior or a bug?

Here is the log:

Sep 22 07:53:22 sarene systemd[1]: Started usbmuxd.service - Socket daemon for the usbmux protocol used by Apple devices.
Sep 22 07:53:22 sarene usbmuxd[8445]: [07:53:22.430][3] usbmuxd v1.1.1^20240915git0b1b233 starting up
Sep 22 07:53:22 sarene usbmuxd[8445]: [07:53:22.430][3] Successfully dropped privileges to 'usbmuxd'
Sep 22 07:53:22 sarene usbmuxd[8445]: [07:53:22.430][3] Using libusb 1.0.29
Sep 22 07:53:22 sarene usbmuxd[8445]: [07:53:22.436][3] Initialization complete
Sep 22 07:53:22 sarene usbmuxd[8445]: [07:53:22.436][3] Enabled exit on SIGUSR1 if no devices are attached. Start a new instance with "--exit" to trigger.
Sep 22 07:53:22 sarene usbmuxd[8445]: [07:53:22.437][2] Skipping switch device 3-13 mode from 1 to 1
Sep 22 07:53:22 sarene usbmuxd[8445]: libusb: warning [op_get_configuration] device unconfigured
Sep 22 07:53:22 sarene usbmuxd[8445]: [07:53:22.437][3] Found usbmux interface for device 3-13: 1
Sep 22 07:53:22 sarene usbmuxd[8445]: [07:53:22.437][3] Changing configuration of device 3-13: 0 -> 4
Sep 22 07:53:22 sarene usbmuxd[8445]: [07:53:22.488][3] Connecting to new device on location 0x3000d as ID 1
Sep 22 07:53:22 sarene usbmuxd[8445]: [07:53:22.488][3] Connected to v2.0 device 1 on location 0x3000d with serial number 533f99b5a132b4545748aef8ea9f7d33b4edf637
Sep 22 07:53:22 sarene usbmuxd[8445]: [07:53:22.513][1] preflight_worker_handle_device_add: The stored pair record for device 533f99b5a132b4545748aef8ea9f7d33b4edf637 is invalid. Removing.
Sep 22 07:53:22 sarene usbmuxd[8445]: [07:53:22.514][1] Device 1: ERROR: socketIsClosed sock_receive returned errno 54
Sep 22 07:53:22 sarene usbmuxd[8445]: [07:53:22.566][1] ERROR: Failed to read '/var/lib/lockdown/533f99b5a132b4545748aef8ea9f7d33b4edf637.plist': No such file or directory
Sep 22 07:53:22 sarene usbmuxd[8445]: [07:53:22.906][1] ERROR: Failed to read '/var/lib/lockdown/533f99b5a132b4545748aef8ea9f7d33b4edf637.plist': No such file or directory
Sep 22 07:53:25 sarene usbmuxd[8445]: [07:53:25.066][1] ERROR: Failed to read '/var/lib/lockdown/533f99b5a132b4545748aef8ea9f7d33b4edf637.plist': No such file or directory
Sep 22 07:53:25 sarene usbmuxd[8445]: [07:53:25.661][1] np_callback: ERROR: Pair failed for device 533f99b5a132b4545748aef8ea9f7d33b4edf637, lockdown error -5

The iPhone is an iPhone X running iOS 16.7.2 with the palera1n jailbreak. I am using the latest version of usbmuxd packaged by Fedora 42, which is 1.1.1^20240915git0b1b233.

[radon-at-beeper]

Strangely, despite the message:

Sep 22 07:53:22 sarene usbmuxd[8445]: [07:53:22.566][1] ERROR: Failed to read '/var/lib/lockdown/533f99b5a132b4545748aef8ea9f7d33b4edf637.plist': No such file or directory

That file does exist and is readable:

{radon@sarene} ~ % ls -lA -d /var/lib/lockdown
drwxrwsr-x. 1 usbmuxd usbmuxd 142 Sep 22 09:40 /var/lib/lockdown
{radon@sarene} ~ % ls -lA /var/lib/lockdown  
total 16
-rw-r--r--. 1 usbmuxd usbmuxd 9409 Sep 22 09:40 533f99b5a132b4545748aef8ea9f7d33b4edf637.plist
-rw-r--r--. 1 usbmuxd usbmuxd  266 Aug 11 12:22 SystemConfiguration.plist

[radon-at-beeper]

I confirmed that the same behavior occurs also with an iPhone 5s running iOS 12.5.7 unmodified.

[mexmer]

check if usbmuxd is not running in jail/chroot, also check security context of folders, might be just some security hardening on your distribution.

[radon-at-beeper]

I don't see anything in the systemd unit for usbmuxd that would indicate it's being run in an unusual way, and I also disabled SELinux enforcement in /etc/selinux/config and see the same behavior, so I don't think it's that.

System information

% cat /usr/lib/systemd/system/usbmuxd.service
[Unit]
Description=Socket daemon for the usbmux protocol used by Apple devices
Documentation=man:usbmuxd(8)

[Service]
ExecStart=/usr/bin/usbmuxd --user usbmuxd --systemd
PIDFile=/run/usbmuxd.pid

% rpm -ql usbmuxd
/usr/bin/usbmuxd
/usr/lib/.build-id
/usr/lib/.build-id/6e
/usr/lib/.build-id/6e/2f69184550f161406e98d05950e3382f024be7
/usr/lib/systemd/system/usbmuxd.service
/usr/lib/sysusers.d/usbmuxd.conf
/usr/lib/tmpfiles.d/usbmuxd.conf
/usr/lib/udev/rules.d/39-usbmuxd.rules
/usr/share/doc/usbmuxd
/usr/share/doc/usbmuxd/AUTHORS
/usr/share/doc/usbmuxd/README.md
/usr/share/licenses/usbmuxd
/usr/share/licenses/usbmuxd/COPYING.GPLv2
/usr/share/licenses/usbmuxd/COPYING.GPLv3
/usr/share/man/man8/usbmuxd.8.gz
/var/lib/lockdown

% sudo systemctl status usbmuxd
● usbmuxd.service - Socket daemon for the usbmux protocol used by Apple devices
     Loaded: loaded (/usr/lib/systemd/system/usbmuxd.service; static)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: active (running) since Tue 2025-09-23 07:44:11 PDT; 8s ago
 Invocation: 89f1223b0d5e4495adae9bec5bb32ccd
       Docs: man:usbmuxd(8)
   Main PID: 115668 (usbmuxd)
      Tasks: 2 (limit: 56673)
     Memory: 2.2M (peak: 4.4M)
        CPU: 114ms
     CGroup: /system.slice/usbmuxd.service
             └─115668 /usr/bin/usbmuxd --user usbmuxd --systemd

% ls -lAdZ /var/lib/lockdown -d -Z
drwxrwsr-x. 1 usbmuxd usbmuxd system_u:object_r:usbmuxd_var_lib_t:s0 234 Sep 23 07:44 /var/lib/lockdown

% rpm -ql selinux-policy-targeted | grep usbmux
/var/lib/selinux/targeted/active/modules/100/usbmuxd
/var/lib/selinux/targeted/active/modules/100/usbmuxd/cil
/var/lib/selinux/targeted/active/modules/100/usbmuxd/hll
/var/lib/selinux/targeted/active/modules/100/usbmuxd/lang_ext

[mexmer]

stop usbmuxd and run it under root (or usbmuxd user) from commandline in foreground, and see if it still throw same error.

[radon-at-beeper]

Yes, same result.

Logs

% sudo usbmuxd -f
[10:39:09.098][3] usbmuxd v1.1.1^20240915git0b1b233 starting up
[10:39:09.098][3] Using libusb 1.0.29
[10:39:09.102][3] Initialization complete
[10:39:13.352][2] Skipping switch device 3-23 mode from 1 to 1
[10:39:13.352][3] Found usbmux interface for device 3-23: 1
[10:39:13.352][3] Changing configuration of device 3-23: 1 -> 4
[10:39:13.442][3] Connecting to new device on location 0x30017 as ID 1
[10:39:13.442][3] Connected to v2.0 device 1 on location 0x30017 with serial number 533f99b5a132b4545748aef8ea9f7d33b4edf637
[10:39:13.527][1] ERROR: Failed to read '/var/lib/lockdown/533f99b5a132b4545748aef8ea9f7d33b4edf637.plist': No such file or directory
[10:39:15.307][1] np_callback: ERROR: Pair failed for device 533f99b5a132b4545748aef8ea9f7d33b4edf637, lockdown error -5
[10:39:16.527][1] ERROR: Failed to read '/var/lib/lockdown/533f99b5a132b4545748aef8ea9f7d33b4edf637.plist': No such file or directory
[10:39:20.305][3] Removed device 1 on location 0x30017
[10:39:23.333][2] Skipping switch device 3-24 mode from 1 to 1
[10:39:23.333][3] Found usbmux interface for device 3-24: 1
[10:39:23.333][3] Changing configuration of device 3-24: 1 -> 4
[10:39:23.425][3] Connecting to new device on location 0x30018 as ID 2
[10:39:23.425][3] Connected to v2.0 device 2 on location 0x30018 with serial number 533f99b5a132b4545748aef8ea9f7d33b4edf637
[10:39:23.441][1] preflight_worker_handle_device_add: The stored pair record for device 533f99b5a132b4545748aef8ea9f7d33b4edf637 is invalid. Removing.
[10:39:23.441][1] Device 2: ERROR: socketIsClosed sock_receive returned errno 54
[10:39:23.530][1] ERROR: Failed to read '/var/lib/lockdown/533f99b5a132b4545748aef8ea9f7d33b4edf637.plist': No such file or directory
[10:40:54.129][3] Removed device 2 on location 0x30018
[10:40:57.351][2] Skipping switch device 3-25 mode from 1 to 1
[10:40:57.351][3] Found usbmux interface for device 3-25: 1
[10:40:57.351][3] Changing configuration of device 3-25: 1 -> 4
[10:40:57.442][3] Connecting to new device on location 0x30019 as ID 3
[10:40:57.442][3] Connected to v2.0 device 3 on location 0x30019 with serial number 533f99b5a132b4545748aef8ea9f7d33b4edf637
[10:40:57.461][1] preflight_worker_handle_device_add: The stored pair record for device 533f99b5a132b4545748aef8ea9f7d33b4edf637 is invalid. Removing.
[10:40:57.461][1] Device 3: ERROR: socketIsClosed sock_receive returned errno 54
[10:40:57.506][1] ERROR: Failed to read '/var/lib/lockdown/533f99b5a132b4545748aef8ea9f7d33b4edf637.plist': No such file or directory
[10:41:00.549][1] np_callback: ERROR: Pair failed for device 533f99b5a132b4545748aef8ea9f7d33b4edf637, lockdown error -5
[10:41:01.415][1] ERROR: Failed to read '/var/lib/lockdown/533f99b5a132b4545748aef8ea9f7d33b4edf637.plist': No such file or directory
[10:41:09.746][3] Removed device 3 on location 0x30019
[10:41:13.320][2] Skipping switch device 3-26 mode from 1 to 1
[10:41:13.320][3] Found usbmux interface for device 3-26: 1
[10:41:13.320][3] Changing configuration of device 3-26: 1 -> 4
[10:41:13.411][3] Connecting to new device on location 0x3001a as ID 4
[10:41:13.411][3] Connected to v2.0 device 4 on location 0x3001a with serial number 533f99b5a132b4545748aef8ea9f7d33b4edf637
[10:41:13.434][1] preflight_worker_handle_device_add: The stored pair record for device 533f99b5a132b4545748aef8ea9f7d33b4edf637 is invalid. Removing.
[10:41:13.435][1] Device 4: ERROR: socketIsClosed sock_receive returned errno 54
[10:41:13.504][1] ERROR: Failed to read '/var/lib/lockdown/533f99b5a132b4545748aef8ea9f7d33b4edf637.plist': No such file or directory
[10:41:15.066][1] np_callback: ERROR: Pair failed for device 533f99b5a132b4545748aef8ea9f7d33b4edf637, lockdown error -5
[10:41:15.618][1] ERROR: Failed to read '/var/lib/lockdown/533f99b5a132b4545748aef8ea9f7d33b4edf637.plist': No such file or directory

[mexmer]

this is really strange, since according to what you posted, it should have access to these files.

you can also try to run it on foreground with alternate config dir, you don't need to copy files there, since those will be created by usbmuxd

for example

ubsmuxd -f -vv -C /tmp/ubsmuxdtest

it should create that folder, and also systemconfiguration.plist and "your device uid".plist file

vv is just for more verbose output

[radon-at-beeper]

Looks like that option was just added recently (2efa75a) and not yet packaged. I cloned the repository and built from source to test. I observed the same behavior.

Log output: https://gist.github.com/radon-at-beeper/4cfb278a3eecf02ab6ff343e0a6f28c9

Certainly it does create the directory and the relevant files, though:

{radon@sarene} usbmuxd[master] % ls -lA /tmp/ubsmuxdtest
total 16
-rw-r--r--. 1 root root 9401 Sep 24 09:02 533f99b5a132b4545748aef8ea9f7d33b4edf637.plist
-rw-r--r--. 1 root root  266 Sep 24 09:01 SystemConfiguration.plist

[mexmer]

from the log it seems there is gvfsd-afc trying to access phone and locks pairing file, at same time you pair it manually trough usbmuxd, so maybe it's issue with threading, when one thread locks file ... can you stop gvfsd (i think, that's gnome virtual filesystem, or something like that, so just stop that thing), then try pair phone again.

[radon-at-beeper]

Ok, I turned off gvfsd-afc (systemctl --user stop gvfs-afc-volume-monitor.service) and ran the test again. This time, at least, there is no annoying popup asking me to trust the device (I guess that was triggered by GNOME), but the behavior is otherwise the same: pairing fails, the trust settings aren't remembered:

{radon@sarene} usbmuxd[master] % sudo ./src/usbmuxd -f -C /tmp/ubsmuxdtest    
[15:27:51.878][3] usbmuxd v1.1.1-71-g2efa75a starting up
[15:27:51.879][3] Configuration directory: /tmp/ubsmuxdtest
[15:27:51.879][3] Using libusb 1.0.29
[15:27:51.884][3] Initialization complete
[15:27:57.294][2] Skipping switch device 3-68 mode from 1 to 1
[15:27:57.294][3] Found usbmux interface for device 3-68: 1
[15:27:57.294][3] Changing configuration of device 3-68: 1 -> 4
[15:27:57.381][3] Connecting to new device on location 0x30044 as ID 1
[15:27:57.381][3] Connected to v2.0 device 1 on location 0x30044 with serial number 533f99b5a132b4545748aef8ea9f7d33b4edf637
[15:28:08.012][1] np_callback: ERROR: Pair failed for device 533f99b5a132b4545748aef8ea9f7d33b4edf637, lockdown error -5
[15:28:14.550][3] Removed device 1 on location 0x30044
[15:28:17.676][2] Skipping switch device 3-69 mode from 1 to 1
[15:28:17.676][3] Found usbmux interface for device 3-69: 1
[15:28:17.676][3] Changing configuration of device 3-69: 1 -> 4
[15:28:17.769][3] Connecting to new device on location 0x30045 as ID 2
[15:28:17.769][3] Connected to v2.0 device 2 on location 0x30045 with serial number 533f99b5a132b4545748aef8ea9f7d33b4edf637
[15:28:19.396][1] np_callback: ERROR: Pair failed for device 533f99b5a132b4545748aef8ea9f7d33b4edf637, lockdown error -5
[15:28:21.655][3] Removed device 2 on location 0x30045

I do note that the filesystem errors are gone, though, those must have been caused by GNOME doing its own thing, incorrectly, and creating files that usbmuxd then noticed it needed to clean up.

Verbose logs here: https://gist.github.com/radon-at-beeper/69abc49b43c9f3ce4be464b66c531cdc
Note that there are no longer any references to gvfsd-afc.

[nikias]

Can you check what OpenSSL version is being used?

[radon-at-beeper]

Judging by the following output I would say OpenSSL 3.2.4:

% rpm -qa | grep ssl    
xmlsec1-openssl-1.2.41-2.fc42.x86_64
apr-util-openssl-1.6.3-22.fc42.x86_64
openssl-libs-3.2.4-4.fc42.x86_64
openssl-3.2.4-4.fc42.x86_64
openssl-devel-3.2.4-4.fc42.x86_64

% ls -lA /usr/lib*/libssl*
-rwxr-xr-x. 1 root root 416440 Aug 13 17:00 /usr/lib64/libssl3.so
lrwxrwxrwx. 1 root root     15 Jul 13 17:00 /usr/lib64/libssl.so -> libssl.so.3.2.4
lrwxrwxrwx. 1 root root     15 Jul 13 17:00 /usr/lib64/libssl.so.3 -> libssl.so.3.2.4
-rwxr-xr-x. 1 root root 904312 Jul 13 17:00 /usr/lib64/libssl.so.3.2.4

I haven't undertaken to install any other version.

[mexmer]

from log it looks now as ssl error. only thing that comes to my mind might be some ssl cipher or algorithm policy, that blocks ciphers used by pairing process

you might try if something mentioned in #207 helps

[radon-at-beeper]

Okay, I can confirm that running sudo update-crypto-policies --set LEGACY immediately resolves the problem, and pairing works transparently now.

Would you like me to add this to a troubleshooting section in the README?