Trying to revive 'ubtd' (Bluetooth file transfer)

PhAndersson

@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

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

lrwxrwxrwx 1 phablet phablet 34 Jan 15 10:50 dbus-org.bluez.obex.service -

I have it too; it's a different thing, it's for the dbus part I think.

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

my app is now able to start obexd by itself if not running already,

It may be possible to activate on demand, but I have no idea how.

PhAndersson

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

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

AuthorizePush

this is denied; I never dabbled much with Apparmor, and certainly not with UT; I notice with some dismay that there are no apparmor logs and I have no clear idea on the better way to enable them unfortunately.

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 ?

PhAndersson

@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.

PhAndersson

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

@PhAndersson

Great ! have happy file exchanges with your car

lduboeuf

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

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

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

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

PhAndersson

@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

PhAndersson

@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).

projectmoon

@PhAndersson I think any spawning of external processes that are not inside the app's ~/.local/share directory require unconfined. And in this case, unconfined would be required since it's using some system executable.

gpatel-fr

@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.

gpatel-fr

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

prevent me from publishing it on the OpenStore

Not sure of that actually, there are applications with a big red scary warning, that do not prevent them to be published.

Also, IIRC the idea on phone OS is that the app is shipped with granular authorizations policy and the user grant these rights or not. I don't see why you could not ship a granular apparmor policy for the app if you wanted to do so.