The iPhone tethering HOWTO works for me, with my iPhone 5c and KDE/Plasma.

For the first time in 3 or 4 years I can download my pics and vids with Gwenview without having to email them to myself.

Thank you so much.

adding to my last comment, ...

I have not managed to transfer files other than to download pictures and videos taken with the iPhone (2020) SE.

I'm using plasma (KDE5).

I have found a way to upload my tunes to the iPhone with Cloud Music using wifi.

Also the SE iPhone (iOS 14.x) plays flac (only tested in Cloud Music so far)

I hope this helps others.

aladedragon wrote:

Vernon wrote:

...you can just delete /lib/udev/rules.d/39-usbmuxd.rules and start usbmuxd from your init....

Hello, can you give me and example of how did you start usbmuxd from your init/rc.local?

Why are you trying to run usbmuxd from rc.local? Did you follow the Iphone Tethering HOWTO here and are experiencing some problems?

To be honest I was stuck in there one year ago, I will have alook onto this link you post. Thanks a lot

For the first time in 3 or 4 years I can download my pics and vids with Gwenview without having to email them to myself.

Thank you so much.

Vernon wrote:

...you can just delete /lib/udev/rules.d/39-usbmuxd.rules and start usbmuxd from your init....

Hello, can you give me and example of how did you start usbmuxd from your init/rc.local?

Why are you trying to run usbmuxd from rc.local? Did you follow the Iphone Tethering HOWTO here and are experiencing some problems?

...you can just delete /lib/udev/rules.d/39-usbmuxd.rules and start usbmuxd from your init....

Hello, can you give me and example of how did you start usbmuxd from your init/rc.local?

Thank you

This solution was considered robust enough for every distribution from Fedora to Debian until they switched to systemd.

I guess that was back when udev did not kill processes. There were issues with this as processes tended to accumulate and stuff.
...

I haven't seen udev kill usbmuxd yet. However, if you are planning to use USB tethering for extended periods of time and are concerned about udev killing usbmuxd, you can just delete /lib/udev/rules.d/39-usbmuxd.rules and start usbmuxd from your init. At one of my small sites without dedicated Internet, I have a small wireless router running OpenWrt where I start usbmuxd in rc.local. When I or someone else connects an IPhone to the wireless router USB port, the whole site gets Internet. When we leave and take our IPhones with us, there is no longer any Internet and only local LAN devices are accessible.

This has worked perfectly for over a year without any intervention.

Tobias is a well-known contrarian who has not contributed his talents to Devuan.

I do make sure to use my real name in everything I say about Devuan. You know me, you can block me at any time if I annoy you.

Hmm, the hint that this work-around might not be as robust as promised on recent Devuan releases is at least not harmful IMHO.

This solution was considered robust enough for every distribution from Fedora to Debian until they switched to systemd.

I guess that was back when udev did not kill processes. There were issues with this as processes tended to accumulate and stuff.

Of course you can not sandbox processes started by udev via RUN, which is trivial using other means I will not name here.

I can think of several options:

• stick with an old version of udev that still allows this

• use a udev replacement that does not have this problem

• write something that watches udev and starts/stops things for it

Unfortunately all of these require the distribution to put in effort, which makes all of them rather unsuited as a quick work-around.

The udev manual states that RUN "can only be used for very short-running foreground tasks" and that udev may kill tasks that run too long or try to double-fork.

So this suggestion is not a robust solution.

This solution was considered robust enough for every distribution from Fedora to Debian until they switched to systemd. Do you have a better solution?

So this suggestion is not a robust solution.

(confetti swirls down on Vernon's head as forum members applaud) 

https://bugs.debian.org/cgi-bin/bugrepo … bug=966403

As root, replace the contents of
/lib/udev/rules.d/39-usbmuxd.rules with the following

# usbmuxd ("Apple Mobile Device" muxer listening on /var/run/usbmuxd)

# Forces iDevices to the last USB configuration and runs usbmuxd
ACTION=="add", SUBSYSTEM=="usb", OWNER="usbmux", ATTR{idVendor}=="05ac", ATTR{idProduct}=="12[9a][0-9a-f]", ENV{USBMUX_SUPPORTED}="1", ATTR{bConfigurationValue}!="$attr{bNumConfigurations}", ATTR{bConfigurationValue}="$attr{bNumConfigurations}", OWNER="usbmux", RUN+="/usr/sbin/usbmuxd -u -U usbmux"

# Exit usbmuxd when the last device is removed
ACTION=="remove", SUBSYSTEM=="usb", ENV{PRODUCT}=="5ac/12[9a][0-9a-f]/*", ENV{INTERFACE}=="255/*", RUN+="/usr/sbin/usbmuxd -x"