@gpatel-fr said in Trying to revive 'ubtd' (Bluetooth file transfer):

@PhAndersson

excellent !
For the record, I remember that you are using Focal on your phone. If you did not look at the last QA for Ubuntu Touch, there was a mention of the 'last' Focal OTA, meaning that 20.04 is on limited life support.

Thanks for letting me know. I'll try to get myself a 3rd phone and flash it with Noble, so I can port the app to it while maintaining the original version for a little while.

Do you know what device offers the best user experience under Noble?

Further update: I successfully tested the SharePlugin part of the app while using the enforcing AppArmor profile, which is great news.

This means that only the main app (used for receiving files) will need an updated AA profile. But this will wait until after publication of the first version.

@gpatel-fr said in Trying to revive 'ubtd' (Bluetooth file transfer):

@PhAndersson

there is no MR yet, it's for this issue

OK, understood -- I take your point and I'll try to publish ASAP.

@gpatel-fr said in Trying to revive 'ubtd' (Bluetooth file transfer):

@PhAndersson

how about setting up a public directory of what you have (if you have cleared the license question) ? It'll allow me to test it under Noble and possibly send a MR to gitlab once I'm sure that it works. Don't want to harass you of course, it's up to you to decide.

Yes, the licensing issue has been cleared up. Michael Zanetti agreed with me using the GPL v3.

What I'm working on right now is getting the code in a state where I could submit it on the OpenStore (with the understanding that it would need a full review as it still uses an unconfined profile). Of course, in the process, I will also push the code to a public Github repository.

Can you clarify what the Gitlab merge request you mentioned would be about? I'm afraid I missed a step here.

Another quick update.

I'm really pleased to announce that I got the SharePlugin part of the app working as well. I successfully pushed a file from my Pixel 3a to my (Linux) laptop over BT, but even more importantly for me, I was able to push selected contacts to my car kit

The user interface is still too rough for the app to be published as is (at this stage, you have to select the target device based on its MAC address, which is far from convenient), but I'm working on it.

@gpatel-fr said in Trying to revive 'ubtd' (Bluetooth file transfer):

@PhAndersson said in Trying to revive 'ubtd' (Bluetooth file transfer):

certain types of D-Bus requested are blocked by AA (such as AuthorizePush

I have actually taken a look at the ubtd code and as I understand it AuthorizePush is a method defined by ubtd for obex.

Correct -- it's still present in my current code.

Looking at the Ubuntu touch bluez code with some dismay, it seems that this method is defined quite officially to allow the obex daemon to send data to a client, squarely fitting your use case, so why is there no apparmor policy for that ? As a wild guess, it looks like an oversight by Canonical that was forwarded by Ubuntu Touch - or even an oversight by Debian, forwarded by Canonical, forwarded by Ubuntu Touch. Maybe a bluetooth policy should exist.

Well, there is a bluetooth policy group, and I used it. But it doesn't seem to cover that use case.

Or maybe it already exists ? looking at usr.sbin.cupsd in my Kubuntu 24.04 installation, I see a string 'network bluetooth'. Maybe adding that to your apparmor profile could strike gold ? Absolutely wild guess of course

If you refer to the network and bluetooth policy groups, I already use both (as you will see in one of my earlier posts), but that was not enough.

If there is a way to extend an app AA profile past the predefined policy groups offered by the platform, I would be interested. Can you point me to a doc. that covers it? I already tried hacking the .apparmor file provided with my app, but clickable didn't seem to approve

@gpatel-fr said in Trying to revive 'ubtd' (Bluetooth file transfer):

@projectmoon said in Trying to revive 'ubtd' (Bluetooth file transfer):

I think any spawning of external processes that are not inside the app's ~/.local/share directory require unconfined.

If 'running an external process' means 'activating a service' via dbusk, not 'spawning', it can be done from confined I think. I did not check how exactly is working this application.

Yes, that was my experience as well. Even with an enforcing AA profile, my app was able to ask D-Bus to start the OBEX daemon if needed.

Only certain types of D-Bus requested are blocked by AA (such as AuthorizePush -- see log extract in one of my posts above).

@lduboeuf said in Trying to revive 'ubtd' (Bluetooth file transfer):

Congrats, So some changes are needed on UT to make it work ?

If your question is: did I need to hack my phone to make the app work in its current state, then the answer is no. As suggested by @gpatel-fr, I just gave it an "unconfined" AA profile (which I understand would prevent me from publishing it on the OpenStore).

So eventually an updated bluetooth AppArmor Policy Group would be needed, I guess (or a extra one dedicated to OBEX).

@gpatel-fr said in Trying to revive 'ubtd' (Bluetooth file transfer):

@PhAndersson

Great ! have happy file exchanges with your car

That won't work yet, unfortunately. For this, I need the SharePlugin to work. That one still crashes as soon as I select it which causes the phone to restart.

More troubleshooting needed

Well, good news! With the "unconfined" AA profile, the app works

The phone successfully received a .jpeg file sent over BT from my laptop:

@gpatel-fr said in Trying to revive 'ubtd' (Bluetooth file transfer):

For now, I have only one positive thing to say: in the application that worked with 16.04, the template was set to 'unconfined'; while this is not generally a great idea, to advance your testing maybe it could be worth a try to add it to the apparmor profile ?

Yes, you're right -- it's certainly worth a try.

OK, yet more updates.

As already indicated above, my app now successfully registers with D-Bus/OBEX:

[20/01/2026 13:50] Creating a QMirClientScreen now
[20/01/2026 13:50] reply QDBusMessage(type=MethodReturn, service=":1.28", signature="", contents=([]) )
[20/01/2026 13:50] creating agent on dbus
[20/01/2026 13:50] registering agent
[20/01/2026 13:50] discovering obex service
[20/01/2026 13:50] OBEX service not found, attempting D-Bus activation
[20/01/2026 13:50] OBEX service activated successfully
[20/01/2026 13:50] found OBEX service at: "org.bluez.obex"
[20/01/2026 13:50] registering agent on obexd-server
[20/01/2026 13:50] Agent registered successfully
[20/01/2026 13:50] have entries: (".", "..", "HubIncoming", "qmlcache", "qtshadercache-arm64-little_endian-lp64") "/home/phablet/.cache/ratatoskr.philipa"
[20/01/2026 13:50] file:///usr/lib/aarch64-linux-gnu/qt5/qml/Lomiri/Components/1.3/Icon.qml:115:5: QML Image: Failed to get image from provider: image://theme/network-cellular-connected
[20/01/2026 13:50] QObject::startTimer: Timers cannot be started from another thread
[20/01/2026 13:52] file:///usr/lib/aarch64-linux-gnu/qt5/qml/Lomiri/Components/1.3/Icon.qml:115:5: QML Image: Failed to get image from provider: image://theme/network-cellular-connected
[20/01/2026 13:52] file:///usr/lib/aarch64-linux-gnu/qt5/qml/Lomiri/Components/1.3/Icon.qml:115:5: QML Image: Failed to get image from provider: image://theme/network-cellular-connected
[20/01/2026 13:52] qt.qpa.mirclient: Attempted to deliver an event to a non-existent window, ignoring.

But when I start the app and try to push a file from the laptop to the phone over BT, obexd logs the following:

[20/01/2026 13:50] OBEX daemon 5.64
[20/01/2026 13:50] Excluding pcsuite
[20/01/2026 13:50] Excluding ftp
[20/01/2026 13:50] Excluding irmc
[20/01/2026 13:50] Excluding mas
[20/01/2026 13:51] CONNECT(0x0), <unknown>(0xff)
[20/01/2026 13:51] CONNECT(0x0), <unknown>(0x0)
[20/01/2026 13:51] PUT(0x2), <unknown>(0xff)
[20/01/2026 13:51] Agent replied with an error: org.freedesktop.DBus.Error.AccessDenied, An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.107" (uid=32011 pid=4463 comm="/usr/lib/bluetooth/obexd -P ftp,irmc,mas,pcsuite -" label="unconfined") interface="org.bluez.obex.Agent1" member="AuthorizePush" error name="(unset)" requested_reply="0" destination=":1.106" (uid=32011 pid=4460 comm="ratatoskr " label="ratatoskr.philipa_ratatoskr_260120124119 (enforce)")
[20/01/2026 13:51] PUT(0x2), Forbidden(0x43)
[20/01/2026 13:51] DISCONNECT(0x1), <unknown>(0xff)
[20/01/2026 13:51] DISCONNECT(0x1), Success(0x20)
[20/01/2026 13:51] disconnected: Transport got disconnected

Looking in journal, another message is found right before the error reported by obexd, this one issued by dbus-daemon (here copied from an earlier test run):

Jan 15 16:44:14 hatshepsut dbus-daemon[2372]: apparmor="DENIED" operation="dbus_method_call"  bus="session" path="/test/agent" interface="org.bluez.obex.Agent1" member="AuthorizePush" name=":1.94" mask="receive" pid=5216 label="ratatoskr.philipa_ratatoskr_260115153557" peer_pid=3539 peer_label="unconfined"

Clearly, the IPC between obexd and the agent registered by my app seems to be blocked by AppArmor. This is the current AA profile for my app:

{
    "policy_groups": [
        "bluetooth",
        "networking",
        "content_exchange",
        "content_exchange_source"
    ],
    "policy_version": 20.04
}

Can anyone tell me what could be missing?

@gpatel-fr said in Trying to revive 'ubtd' (Bluetooth file transfer):

@PhAndersson

the other override is needed because of the specific 24.04 problem, you should not need it.

OK -- thanks.

Maybe all that is needed is to enable again the service.

What's the result of

systemctl --user status obex

obex.service is still enabled -- here is the requested output:

● obex.service - Bluetooth OBEX service
     Loaded: loaded (/usr/lib/systemd/user/obex.service; enabled; vendor preset: enabled)
    Drop-In: /usr/lib/systemd/user/obex.service.d
             └─ubuntu-touch-session.conf
     Active: inactive (dead)

also, is there a symbolic link to the service under ~/.config/systemd/user/default.target.wants ?
if not systemd will not start it.

Well -- that's a good hint

As it turns out, the folder called ~/.config/systemd/user/default.target.wants does not exist at all. There is a folder called graphical-session.target.wants but the symlink is not there either. The symlink is created one level above, i.e. in ~/.config/systemd/user/. Here is the ls -l output:

total 20
lrwxrwxrwx 1 phablet phablet   34 Jan 15 10:50 dbus-org.bluez.obex.service -> /usr/lib/systemd/user/obex.service
-rw-rw-r-- 1 phablet phablet  768 Oct  4 16:55 dekkod-notify.service
-rw-rw-r-- 1 phablet phablet  716 Oct  4 16:55 dekkod.service
drwxr-xr-x 2 phablet phablet 4096 Mar 27  2025 graphical-session.target.wants
-rw-rw-r-- 1 phablet phablet  332 Mar 27  2025 osmscout-server.service
-rw-rw-r-- 1 phablet phablet  174 Mar 27  2025 osmscout-server.socket

By way of comparison, on my laptop running openSUSE Leap 15.6, the OBEX symlink is created in the exact same place (and obexd successfully starts when I log in), so I don't know whether or not it's enough to explain why the service fails to start on the phone.

This being said, my app is now able to start obexd by itself if not running already, so that aspect has become less critical.

@gpatel-fr said in Trying to revive 'ubtd' (Bluetooth file transfer):
EDIT: after some searching, and finding this github issue, I found the trick to add another override and after setting enable-linger for phablet with loginctl, the obex service is running after a restart.

I just tried the enable-linger trick on 20.04:

$ loginctl enable-linger

then confirmed that it was set using

$ loginctl user-status

but after power-cycling the phone, the OBEX daemon still won't start automatically even though its unit file is still enabled.

You mentioned "another override": was there something else to do?

@gpatel-fr said in Trying to revive 'ubtd' (Bluetooth file transfer):

@PhAndersson said in Trying to revive 'ubtd' (Bluetooth file transfer):
yeah, that's a 24.04 thing. Before Ubuntu was putting the executable under /usr/lib.

I have filed an issue on gitlab.

Splendid! Many thanks.

There is progress. I'm happy to report that the D-Bus registration issue that manifested itself through the following error message:

Error registering agent for the default adapter: QDBusError("org.freedesktop.DBus.Error.ServiceUnknown", "The name org.bluez.obex was not provided by any .service files")

is resolved. My mistake. I tried to connect to OBEX over the system bus, when it runs on the session bus.

Still no file transfer, though.

@Vlad-Nirky Sure -- that would be great!

I plan to attend the "State of FOSS on mobile" lecture (https://fosdem.org/2026/schedule/event/SW83YJ-state_of_foss_on_mobile/), so we could meet Saturday morning outside UB4.132 at 11:00.

If this doesn't work for you, alternative proposals are more than welcome

Weather permitting, I'll ride my motorbike to get there, so I'll wear a dark grey/black Rev'It padded jacket and a small blue + grey Swiss Gear rucksack.

@gpatel-fr said in Trying to revive 'ubtd' (Bluetooth file transfer):

@PhAndersson

I wonder how the obex service runs at all for you. It does not for me.

@lduboeuf already mentioned that obexd wouldn't start on 24.04. I don't use 24.04 yet myself, so I can't confirm.

On my FP5 running 24.04.1.1, I get:

phablet@ubuntu-phablet:~$ systemctl --user cat obex
# /usr/lib/systemd/user/obex.service
[Unit]
Description=Bluetooth OBEX service

[Service]
Type=dbus
BusName=org.bluez.obex
ExecStart=/usr/libexec/bluetooth/obexd

[Install]
Alias=dbus-org.bluez.obex.service

# /usr/lib/systemd/user/obex.service.d/ubuntu-touch-session.conf
[Service]
ExecStart=
ExecStart=/usr/lib/bluetooth/obexd -P ftp,irmc,mas,pcsuite -r $HOME

That content looks identical to what it is on 20.04.

as /usr/lib/bluetooth/obexd does not exist, the service fails to start.

Are you sure /usr/lib/bluetooth/obexd does not exist on 24.04? It is normally provided by the same package as the unit file whose content you just showed (package bluez-obexd).

EDIT: after some searching, and finding this github issue, I found the trick to add another override and after setting enable-linger for phablet with loginctl, the obex service is running after a restart.

Thanks a lot for that -- maybe this would the issue on 20.04 as well. I'll try.

Not that I can test anything involving Bluetooth for lack of a suitable peripheral

Further updates:

The obex.service systemd unit was in fact disabled by default. I enabled it with systemctl --user enable obex.service and then performed a full power-cycle on the phone.

After rebooting, obexd was still not running.

systemd reports the following about the service:

● obex.service - Bluetooth OBEX service
     Loaded: loaded (/usr/lib/systemd/user/obex.service; enabled; vendor preset: enabled)
    Drop-In: /usr/lib/systemd/user/obex.service.d
             └─ubuntu-touch-session.conf
     Active: inactive (dead)

I didn't find anything in 'journal' that could explain why systemd failed to start the unit -- obexd logs its version during startup and even that wasn't present, so I don't believe it's a case of it dying prematurely.

Of course, I'm still able to start the service manually with systemctl --user start obex.service, and in this case, it keeps running until I power-cycle the phone.

@Vlad-Nirky Thanks.
I'll try to be there as well on Saturday -- there's a whole track dedicated to "FOSS on Mobile": https://fosdem.org/2026/schedule/track/foss-on-mobile/ (won't be able to follow all of it, though).
If I see you, I'll introduce myself