How to Use Bluetooth File Transfer on Fedora
You right-click the Bluetooth icon in GNOME, select "Send File to Device", and the transfer aborts immediately. Or you are on a headless server, trying to push a log file to your phone, and the command hangs without feedback. The Bluetooth hardware works. Audio streams fine. File transfer is the one thing that refuses to cooperate. This is usually a missing server package or a firewall rule, not a broken radio.
What is actually happening
Bluetooth is a stack of protocols. Audio uses A2DP. Keyboards use HID. File transfer uses OBEX (Object Exchange) over RFCOMM. Fedora ships with the bluez stack, which handles the radio, pairing, and basic profiles. The file transfer server component lives in a separate package called bluez-obex-server. If that package is not installed, the Bluetooth daemon has no process listening for incoming file requests. Your phone sends a request, the kernel drops the packet, and the transfer fails.
The GUI in GNOME Files relies on this server. Without it, the "Send File" menu item may be grayed out or crash silently. OBEX is also a single-file protocol. It does not support directories. You cannot drag a folder over Bluetooth. You must send files one by one. This design dates back to the early days of mobile phones. It keeps the protocol simple but makes bulk transfers painful.
The fix
Install the required packages. Fedora separates the core Bluetooth stack from the file transfer server for security and footprint reasons. You need bluez for the radio, bluez-obex-server for the file transfer daemon, and obexftp for command-line transfers.
# bluez provides the core Bluetooth daemon and tools.
# bluez-obex-server enables the OBEX file transfer protocol.
# obexftp is the command-line client for sending and receiving files.
sudo dnf install bluez bluez-obex-server obexftp
# Enable the Bluetooth service and start it immediately.
# This ensures the radio is active and the OBEX socket is listening.
sudo systemctl enable --now bluetooth
Verify that the OBEX server is running. The package usually installs a socket unit that activates the server on demand. Check the status to confirm the system is ready to accept connections.
# Check if the OBEX service is active.
# It may show as "inactive (dead)" if no connection is currently pending.
# This is normal. The socket unit will wake it when a transfer starts.
systemctl status obex.service
Pair your device. Pairing establishes a secure link. Trusting the device allows automatic reconnection without user interaction. File transfers initiated from the remote device require the device to be trusted.
# Enter the Bluetooth control interface.
bluetoothctl
# Start scanning for nearby devices.
# Wait for your device to appear in the list.
scan on
# Pair with the device using its MAC address.
# You may need to confirm a PIN on both devices.
pair <MAC_ADDRESS>
# Trust the device to allow automatic reconnection.
# This is required for file transfers initiated from the phone.
trust <MAC_ADDRESS>
# Exit the controller.
quit
Configure the firewall. Fedora uses firewalld by default. The bluetooth service includes rules for OBEX traffic. If the service is not added to the active zone, the firewall will drop incoming OBEX packets.
# Add the bluetooth service to the permanent configuration.
# This includes rules for OBEX, A2DP, and other Bluetooth profiles.
sudo firewall-cmd --permanent --add-service=bluetooth
# Reload the firewall to apply the changes immediately.
# Always reload after modifying permanent rules.
sudo firewall-cmd --reload
Run firewall-cmd --reload after every rule change. The runtime configuration and the persistent configuration will diverge if you skip this step.
Transferring files
Use the command line for precise control or automation. The obexftp tool connects to the remote device and pushes or pulls files. The -b flag specifies the Bluetooth address. The -put flag uploads a file. The -get flag downloads a file.
# Send a file to a paired device.
# Replace <MAC_ADDRESS> with the device's Bluetooth address.
# Replace /home/user/document.pdf with the path to your file.
obexftp -b <MAC_ADDRESS> -put /home/user/document.pdf
# Receive a file from a device.
# The file will be saved in the current directory.
# Replace <MAC_ADDRESS> and received_file.txt with actual values.
obexftp -b <MAC_ADDRESS> -get received_file.txt
Use the graphical interface for desktop workflows. Open the "Files" application (Nautilus). Navigate to the "Places" sidebar. Your paired Bluetooth device should appear if it is trusted and within range. Click the device to mount it. Drag and drop files into the window to initiate the transfer. This method uses the same bluez-obex-server backend but abstracts the command-line complexity.
If the device does not appear in Nautilus, check the Bluetooth settings menu. Ensure the device is connected and trusted. Some phones require you to accept the file transfer request on the phone screen before the transfer proceeds.
Check the logs before you blame the hardware. The radio is rarely the problem.
Verify it worked
Confirm the transfer by checking the file system and the logs. On the receiving end, list the directory to ensure the file arrived with the correct size. On the sending end, check the Bluetooth daemon logs for OBEX connection events.
# List the file to verify size and permissions.
ls -l /home/user/received_file.txt
# Check the Bluetooth daemon logs for OBEX activity.
# The -x flag adds explanatory text. The -e flag jumps to the end.
# Look for lines mentioning "OBEX" or "ObjectPush".
journalctl -xeu bluetooth
If the transfer failed, the logs will show the exact reason. A "Connection refused" error means the OBEX server is not running. A "Permission denied" error points to SELinux or file permissions. A "Timeout" error indicates the remote device did not accept the request.
Read the actual error before guessing.
Common pitfalls and what the error looks like
SELinux can block file transfers if policies are misconfigured. The default policies allow OBEX traffic for standard users. Custom configurations or non-standard file locations may trigger denials. Check the audit log for AVC denials.
type=AVC msg=audit(1678886400.123:456): avc: denied { write } for pid=1234 comm="obexd" name="documents" dev="sda1" ino=789 scontext=system_u:system_r:bluetooth_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir permissive=0
Do not disable SELinux to fix this. Use ausearch to find the denial and restorecon to fix the context. Temporarily set SELinux to permissive mode only for testing. Revert it immediately after.
# Search for recent SELinux denials related to Bluetooth.
ausearch -m avc -ts recent | grep bluetooth
# Restore the default security context for the directory.
# This fixes most permission issues without disabling SELinux.
sudo restorecon -Rv /path/to/directory
The obexftp command may fail with Error: Connection refused. This means the OBEX server is not listening. Verify that bluez-obex-server is installed and the obex.service is enabled. The Error: Permission denied message means SELinux or file permissions are blocking access. Check the audit log. The Error: Timeout message means the remote device did not respond. Ensure the device is paired, trusted, and the file transfer request is accepted on the phone screen.
Edit configuration in /etc/bluetooth/. Files in /usr/lib/bluetooth/ are managed by the package manager and will be overwritten on update.
Trust the package manager. Manual file edits drift, snapshots stay.
When to use this vs alternatives
Use obexftp when you are on a server without a desktop environment and need to push a config file to a phone for backup. Use GNOME Files when you are on a desktop and want drag-and-drop simplicity. Use MTP or USB tethering when you need to transfer large video files or directories. OBEX is slow and single-file only. Use cloud sync when you need files available across multiple devices without physical proximity. Stay on the upstream Workstation if you only deviate from the defaults occasionally.