Any news here?

I suggest changing /usr/share/dbus-1/services/org.bluez.obex.service to refer to SystemdService=obex.service directly. That way it does not need to be enabled by default.

Or are there alternative implementations of org.bluez.obex?

I don't know of any alternative providers of org.bluez.obex, and even if there were, they could just conflict with bluez-obexd :-)

Since I'm no longer actively maintaining bluez *and* I have almost no knowledge of dbus/systemd/service interactions, the fastest way forward would probably be for you to just submit a patched bluez package to Base:System :-) (or provide me a complete org.bluez.obex.service). If I'm trying to fix this, chances are high that I would
a) break it
b) rip up a security hole

:-)

(In reply to Stefan Seyfried from comment #2)
> I don't know of any alternative providers of org.bluez.obex, and even if
> there were, they could just conflict with bluez-obexd :-)
> 
> Since I'm no longer actively maintaining bluez *and* I have almost no
> knowledge of dbus/systemd/service interactions, the fastest way forward
> would probably be for you to just submit a patched bluez package to
> Base:System :-) (or provide me a complete org.bluez.obex.service). If I'm
> trying to fix this, chances are high that I would
> a) break it
> b) rip up a security hole
> 
> :-)

The DBus file is from upstream, so ideally we find a way that either the upstream approach works for us (is that documented somewhere?) or we fix it upstream. Currently I don't have time for that, and while I could just submit a workaround patch we all know how temporary that will be...

I confirm the problem.

By default, we cannot send/receive files, and we cannot scan the folder tree of the smartphone according to exchange files by dragging and dropping.

We must install manually bluez-obex package with :

sudo zypper in bluez-obex

Then we encounter another problem : obex service is not started when activating bluetooth. We must manually start the obex service with :

systemctl --user start obex

 to get automatically obexd enabled you must excute :

systemctl --user enable obex

It has been brought to upstream before [1] but wasn't addressed at the time.

So I posted to the #bluetooth channel in Slack:

> Hello! I'm investigating why transferring files doesn't work out of the box. Upstream provided dbus service requires a systemd user service to be placed at /usr/lib/systemd/user/dbus-org.bluez.obex.service while the also provided service is called obex.service. Debian patches /usr/share/dbus-1/services/org.bluez.obex.service to activate obex directly: SystemdService=obex.service, while ArchLinux prefers a ln to the required service name. In particular the [Alias] section in the systemd service is only used when a service is enabled before hand, which would be yet another way to handle activation. openSUSE doesn't do anything and I believe neither does Fedora. Would it be possible to upstream the debian solution? Unless it's really expected to distros to handle this which should be fine as well but I thought it would be worthwhile to bring this to upstream. Thank you!

I will keep you posted.

[1] https://marc.info/?l=linux-bluetooth&m=148096094716386&w=2

Hi,
I'm sorry to bother you.
I just installed openSUSE Tumbleweed fresh after a while and I'm still experiencing this bug, now the name of the package has changed from bluez-obex to bluez-obexd and last time I checked when I tried to enable the service via systemctl it said that it didn't exist, even if I installed the package.
Are there any news about the Slack message in the #bluetooth channel?
Thank you in advance.

(In reply to Gabriele Avi from comment #7)
> Hi,
> I'm sorry to bother you.
> I just installed openSUSE Tumbleweed fresh after a while and I'm still
> experiencing this bug, now the name of the package has changed from
> bluez-obex to bluez-obexd and last time I checked when I tried to enable the
> service via systemctl it said that it didn't exist, even if I installed the
> package.

The systemd service name hasn't changed, perhaps you missed the --user argument or spelled it wrong. The updated procedure would be:

$ sudo zypper in bluez-obexd
$ systemctl --user start obex

> Are there any news about the Slack message in the #bluetooth channel?
> Thank you in advance.

I was asked to send a patch, I did, got feedback which I have yet to address.

(In reply to André Werlang from comment #8)
> (In reply to Gabriele Avi from comment #7)
> > Hi,
> > I'm sorry to bother you.
> > I just installed openSUSE Tumbleweed fresh after a while and I'm still
> > experiencing this bug, now the name of the package has changed from
> > bluez-obex to bluez-obexd and last time I checked when I tried to enable the
> > service via systemctl it said that it didn't exist, even if I installed the
> > package.
> 
> The systemd service name hasn't changed, perhaps you missed the --user
> argument or spelled it wrong. The updated procedure would be:
> 
> $ sudo zypper in bluez-obexd
> $ systemctl --user start obex
> 
> > Are there any news about the Slack message in the #bluetooth channel?
> > Thank you in advance.
> 
> I was asked to send a patch, I did, got feedback which I have yet to address.

Thank you for your kind response, now I retried enabling the service via systemd and it worked!

Is there any update on this bug? Has the issue been reported upstream? Do you have a link?