Can't receive files from phone over Bluetooth

Bug #1535030 reported by Sam Freilich
72
This bug affects 16 people
Affects Status Importance Assigned to Milestone
obexd (Ubuntu)
Confirmed
Undecided
Unassigned
Bionic
Confirmed
Undecided
Unassigned

Bug Description

When I try to send files from my Android phone to my computer over Bluetooth, the phone connects successfully but then refuses to send the file with the error message "Transfer forbidden by target device".

The following ends up in my /var/log/syslog:

Jan 16 22:54:07 eristic obexd[2234]: CONNECT(0x0), (null)(0xffffffff)
Jan 16 22:54:07 eristic obexd[2234]: CONNECT(0x0), (null)(0x0)
Jan 16 22:54:07 eristic obexd[2234]: PUT(0x2), (null)(0xffffffff)
Jan 16 22:54:07 eristic obexd[2234]: open(/home/sfreilich/Downloads/IMG_20160114
_121340.jpg): Operation not permitted (1)
Jan 16 22:54:07 eristic obexd[2234]: PUT(0x2), FORBIDDEN(0x43)
Jan 16 22:54:07 eristic gnome-session[1610]: ** (zeitgeist-datahub:2255): WARNIN
G **: zeitgeist-datahub.vala:212: Error during inserting events: GDBus.Error:org
.gnome.zeitgeist.EngineError.InvalidArgument: Incomplete event: interpretation,
manifestation and actor are required
Jan 16 22:54:07 eristic obexd[2234]: DISCONNECT(0x1), (null)(0xffffffff)
Jan 16 22:54:07 eristic obexd[2234]: DISCONNECT(0x1), SUCCESS(0x20)
Jan 16 22:54:07 eristic obexd[2234]: disconnected: Transport got disconnected
Jan 16 22:54:07 eristic bluetoothd[664]: Unable to get io data for Object Push:
getpeername: Transport endpoint is not connected (107)

Strangely, the expected file is create in my Downloads folder, but the file is empty:

$ ls -l ~/Downloads/
total 0
-rw------- 1 sfreilich sfreilich 0 Jan 16 22:54 IMG_20160114_121340.jpg

Tags: bionic
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in obexd (Ubuntu):
status: New → Confirmed
Revision history for this message
Jonathan Kamens (jik) wrote :

I've spent some time looking into this.

When I run strace on the obexd process and toggle the "Receive files in Downloads folder over Bluetooth" setting in Personal File Sharing Preferences, I see the obexd process receiving messages as a result of the toggle, so that setting seems to be propagated as expected to the daemon.

In contrast, when I change the "Accept files" setting back and forth between "Always" and "Only for set up devices", I do _not_ see the obexd process receiving any messages as a result of that change. So it appears to me that this setting is not being propagated from Personal File Sharing Preferences to obexd. This is also true if I modify the setting in dconf-editor.

Not only that, but changing that setting to "Always" and rebooting also has no effect, so I'm fairly certain that this setting is simply being ignored.

So, in short, "Receive files in Downloads folder over Bluetooth" can be successfully being enabled, but "Accept files" always gets set to "bonded", regardless of what Personal File Sharing Preferences says. So why is it failing in that state?

Investigating further, I see that obexd is trying to save sent files in the user's "Downloads" directory. I've tried, unsuccessfully, to figure out where it's getting that directory path from. I _think_ it's coming from DBus somehow, but I don't understand how any of that stuff works, so I'm not certain.

Anyway, the problem is that obexd requires downloads to go underneath the user's root path, and the user's root path is defaulting to ~/.cache/obexd, so since ~/Downloads isn't underneath ~/.cache/obexd, it's rejecting the transfer.

Related bug: the "Require remote devices to bond with this computer" setting is under "Share Files over Bluetooth" in Personal File Sharing Preferences and is greyed out when "Share public files over bluetooth" is disabled, but the description for this setting in dconf-editor is "Whether Bluetooth clients need to pair with the computer to send files," so I think this setting is in the wrong place, and should actually be under "Receive Files over Bluetooth".

Related bug: The type of the bluetooth-accept-files setting within the schema org.gnome.desktop.file-sharing should have a pop-up menu of possible values in dconf-editor but does not.

In short, there are four different bugs that need to be fixed:

1. "Accept files" setting of "Always" vs. "Only for set up devices" needs to be propagated correctly from Personal File Sharing Preferences / dconf to obexd.

2. Whatever is providing settings to obexd needs to set its root path to ~ rather than ~/.cache/obexd, so that file transfers into ~/Downloads will work. Either that, or the download directory -- wherever that is coming from, I can't figure it out exactly -- sent to obexd needs to be ~/.cache/obexd rather than ~/Downloads.

3. The "Require remote devices to bond with this computer" setting in Personal File Sharing Preferences is in the wrong place and needs to be moved.

4. The "bluetooth-accept-files" setting within the schema org.gnome.desktop.file-sharing needs to have a menu of valid values.

Revision history for this message
Olivier Jean (oje) wrote :

Just my 2 cents for a workaround, I am just a user of Ubuntu (14.04 LTS and 15.10), and thanks for your explanations Jonathan, I managed to make it work by changing a line in the file /usr/share/dbus-1/services/org.bluez.obex.service , adding the "-r" setting :

Exec=/usr/lib/bluetooth/obexd -r /home/jean

Regards.

Revision history for this message
Sam Freilich (l33tminion) wrote :

That works, but presumably only for a specific user. Would there be some issue with using /home instead? Would /home/$USER work?

Rolf Leggewie (r0lf)
tags: added: bionic
Revision history for this message
Aex Rauch (centaurie) wrote :

In bionic transfare to both sides not working.

 systemctl --user start obex

and dry again if working systemctl enable --user obex.service

Rolf Leggewie (r0lf)
Changed in obexd (Ubuntu Bionic):
status: New → Confirmed
Rolf Leggewie (r0lf)
summary: - Can't recieve files from phone over Bluetooth
+ Can't receive files from phone over Bluetooth
Revision history for this message
Neal McBurnett (nealmcb) wrote :

I had this problem or a similar one: repeatedly failing to receive an image shared from android to Ubuntu. I got this message on Android 9: "Bluetooth share: File IMG.... not sent",

and this FORBIDDEN message in syslog from obexd:

 Nov 9 10:35:17 sn obexd[24314]: CONNECT(0x0), (null)(0xffffffff)
 Nov 9 10:35:17 sn obexd[24314]: CONNECT(0x0), (null)(0x0)
 Nov 9 10:35:17 sn obexd[24314]: PUT(0x2), (null)(0xffffffff)
 Nov 9 10:35:17 sn obexd[24314]: PUT(0x2), FORBIDDEN(0x43)
 Nov 9 10:35:17 sn obexd[24314]: DISCONNECT(0x1), (null)(0xffffffff)
 Nov 9 10:35:17 sn obexd[24314]: DISCONNECT(0x1), SUCCESS(0x20)
 Nov 9 10:35:17 sn bluetoothd[1341]: Unable to get io data for Object Push: getpeername: Transport endpoint is not connected (107)
 Nov 9 10:35:17 sn obexd[24314]: disconnected: Transport got disconnected

But then I tried (for the first time) sending a file from Ubuntu to Android. Note
that the UI is sufficiently unintuitive that I had
no idea how to do that until I ran across this description:

https://help.ubuntu.com/stable/ubuntu-help/bluetooth-send-file.html.en

After successfully sending one file that way, sharing succeeded in the other direction.

the FORBIDDEN message changed to CONTINUE:

 Nov 9 11:06:21 sn obexd[24314]: CONNECT(0x0), (null)(0xffffffff)
 Nov 9 11:06:21 sn obexd[24314]: CONNECT(0x0), (null)(0x0)
 Nov 9 11:06:21 sn obexd[24314]: PUT(0x2), (null)(0xffffffff)
 Nov 9 11:06:21 sn obexd[24314]: PUT(0x2), CONTINUE(0x10)
 Nov 9 11:06:22 sn rtkit-daemon[2739]: Supervising 3 threads of 1 processes of 1 users.
 Nov 9 11:06:22 sn rtkit-daemon[2739]: Successfully made thread 25043 of process 3676 (n/a) owned by '1000' RT at priority 5.
 Nov 9 11:06:22 sn rtkit-daemon[2739]: Supervising 4 threads of 1 processes of 1 users.
 Nov 9 11:06:22 sn pulseaudio[3676]: [pulseaudio] module-loopback.c: Cannot set requested source latency of 66.67 ms, adjusting to 135.29 ms

Several minutes later, I got an Ubuntu popup notification that it succeeded, and saw this:

 Nov 9 11:09:14 sn obexd[24314]: DISCONNECT(0x1), (null)(0xffffffff)
 Nov 9 11:09:14 sn obexd[24314]: DISCONNECT(0x1), SUCCESS(0x20)
 Nov 9 11:09:14 sn obexd[24314]: disconnected: Transport got disconnected
 Nov 9 11:09:14 sn bluetoothd[1341]: Unable to get io data for Object Push: getpeername: Transport endpoint is not connected (107)
 Nov 9 11:09:23 sn wpa_supplicant[1597]: wlp3s0: WPA: Group rekeying completed with 5c:e2:8c:2c:f0:e7 [GTK=TKIP]

Note also that for a while I assumed that my problem was the message "disconnected: Transport got disconnected", but that seems normal whether or not the transfer succeeds.

I hope that helps someone....

Revision history for this message
Neal McBurnett (nealmcb) wrote :

Note that I was running Ubuntu 18.04.3 Bionic with Gnome

Revision history for this message
Emmanuel (ubuntu-oi) wrote :

Hi, I got similare problem.
I can't receive files from bluetooth for users in user group (as defined profile in "user and group" GUI)
It's ok for user in admin group
on some users, i just see a lock near the bluetooth symbol

here is the syslog

I could provide information if it's required
I'm running xubuntu 18.04 fully updated

Apr 27 09:31:53 MS-7756 bluetoothd[995]: Unable to get io data for Object Push: getpeername: Transport endpoint is not connected (107)
Apr 27 09:33:12 MS-7756 obexd[1708]: CONNECT(0x0), (null)(0xffffffff)
Apr 27 09:33:12 MS-7756 obexd[1708]: CONNECT(0x0), (null)(0x0)
Apr 27 09:33:12 MS-7756 obexd[1708]: PUT(0x2), (null)(0xffffffff)
Apr 27 09:33:12 MS-7756 obexd[1708]: PUT(0x2), FORBIDDEN(0x43)
Apr 27 09:33:12 MS-7756 obexd[1708]: DISCONNECT(0x1), (null)(0xffffffff)
Apr 27 09:33:12 MS-7756 obexd[1708]: DISCONNECT(0x1), SUCCESS(0x20)
Apr 27 09:33:12 MS-7756 obexd[1708]: disconnected: Transport got disconnected
Apr 27 09:33:12 MS-7756 bluetoothd[995]: Unable to get io data for Object Push: getpeername: Transport endpoint is not connected (107)
A

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.