Trying to revive 'ubtd' (Bluetooth file transfer)

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.