Connect Android and iOS Devices to Linux with GSConnect
Moving a file between a phone and a Linux desktop should not require email, a USB cable, or a third-party cloud account. On a GNOME-based Linux system, GSConnect speaks to the KDE Connect application on a phone over the local network. It brings clipboard sharing, notifications, file transfer, media controls, and remote input into one workflow.
This article targets GNOME desktops. Plasma users should install and use kdeconnect directly rather than GSConnect. GSConnect is a complete GNOME Shell implementation of the KDE Connect protocol, with Nautilus integration and support for Chromium and Firefox. Do not run it alongside the KDE Connect desktop application: the GNOME Extensions page explicitly says that GSConnect will not work with KDE Connect installed.1
Architecture: local network, not a cable
The setup has two endpoints:
- The GSConnect extension running inside GNOME Shell on Linux.
- The KDE Connect application running on the phone.
When both endpoints can reach the same local network, they discover one another, the user confirms a pairing request, and a trust relationship is established. Traffic moves directly between the devices. The Android app description states that data is sent through the local network rather than the Internet or a KDE server, and is protected with end-to-end TLS encryption.2
This distinction matters: GSConnect is not a USB phone-mounting tool. The devices need a shared Wi-Fi network, or an Ethernet/Wi-Fi setup on the same local subnet with discovery allowed by the access point. Guest networks and AP/client isolation commonly prevent discovery.
Android and iOS: one protocol, different capability sets
Android provides the most complete GSConnect experience. Common uses include shared clipboard, sending files and URLs, desktop notification mirroring, SMS and call notifications, a virtual touchpad/keyboard, media-player controls, and wireless access to phone files.2
An official KDE Connect app is also available for iPhone and iPad. Its App Store listing includes shared clipboard, file and URL sharing, a virtual touchpad and keyboard, presentation remote control, and remote commands.3 iOS, however, has stricter background-execution and system-permission rules than Android. Do not assume Android capabilities such as SMS access, call history, broad notification mirroring, or persistent filesystem access will be available on iOS. Check the plugin screens in both the phone app and GSConnect device settings for the capabilities actually exposed by your version.
On either platform, evaluate permissions by feature. Android, for example, may require notification access for notification forwarding and accessibility access for remote input.2 Disabling unused plugins reduces both unnecessary permissions and attack surface.
Installing GSConnect on Arch Linux
For GNOME on Arch Linux, GSConnect is packaged in the AUR as gnome-shell-extension-gsconnect. First, make sure the system is current and that a GNOME session is available:
1
2
sudo pacman -Syu
sudo pacman -S gnome-shell gnome-extensions
Then install the extension through your preferred AUR helper. This example uses yay:
1
yay -S gnome-shell-extension-gsconnect
If you do not use yay, inspect the package’s PKGBUILD on the AUR and build it through the normal makepkg -si workflow. Inspecting an AUR build recipe is not ceremony: its build steps execute on your machine.
After installation, enable the extension through the GNOME Extensions application or from a terminal using its UUID:
1
2
gnome-extensions enable org.gnome.Shell.Extensions.GSConnect
gnome-extensions list --enabled
On a Wayland session, the familiar Alt+F2, then r GNOME Shell restart does not apply. Log out and back in if the extension does not appear. Once it is enabled, the GSConnect menu is available from the top bar, where devices can be discovered and pairing requests accepted.
On a non-GNOME desktop,
kdeconnectis available in the official Arch repositories. ArchWiki recommends GSConnect instead ofkdeconnectfor better GNOME integration.4
Pairing the devices
- Connect the phone and computer to the same trusted local network.
- Install the official KDE Connect application from Google Play on Android or the App Store on iPhone/iPad.23
- Open GSConnect from GNOME’s top bar and KDE Connect on the phone.
- Send a pairing request from either device and accept it on the other.
- Enable only the plugins you need and choose a destination directory for received files.
Pairing normally survives reboots. Removing the mobile application, clearing GSConnect data, or unpairing from either endpoint requires a new confirmation.
Arch networking and firewall configuration
The KDE Connect family uses the 1714-1764 range over both UDP and TCP for discovery and data connections.54 A default Arch installation with no active firewall may need no extra rule. If you restrict incoming traffic with ufw, firewalld, or nftables, allow this range only on a trusted local-network interface.
UFW
1
2
sudo ufw allow in on wlan0 to any port 1714:1764 proto tcp
sudo ufw allow in on wlan0 to any port 1714:1764 proto udp
wlan0 is only an example. Check the real interface name with ip link; on a wired desktop it might be enp5s0. Constraining the rule to the LAN interface is safer than exposing these service ports on every network.
firewalld
1
2
3
sudo firewall-cmd --permanent --zone=home --add-port=1714-1764/tcp
sudo firewall-cmd --permanent --zone=home --add-port=1714-1764/udp
sudo firewall-cmd --reload
Confirm that home is assigned to the intended trusted LAN interface:
1
firewall-cmd --get-active-zones
nftables
If you maintain your own inet filter table, add the equivalent of these rules to the input chain before its final reject rule:
iifname "wlan0" tcp dport 1714-1764 accept
iifname "wlan0" udp dport 1714-1764 accept
Add the rules to the appropriate persistent structure in /etc/nftables.conf, and validate syntax before applying it with sudo nft -c -f /etc/nftables.conf. Do not blindly add a rule to a live firewall: inspect the existing table and chain layout first with sudo nft list ruleset.
Troubleshooting: why is the device missing?
Avoid toggling plugins at random. Verify the integration one layer at a time:
- Connectivity: Are both endpoints on the same IP network? Is there a guest Wi-Fi, VLAN, client-isolation, or VPN issue?
- Discovery: Does the firewall permit the required range over both TCP and UDP? On a host with several network cards, did you permit the correct interface?
- Application: Is GSConnect enabled? Does
gnome-extensions list --enabledinclude it? Is the Android/iOS app open and allowed to use the local network? - Pairing: Remove a stale pair at both endpoints and request a new one. On networks that block broadcasts, KDE Connect for Android can add a device by IP address; ArchWiki also suggests refreshing the device list and using IP-based addition when a phone is not found.4
If the issue began after a GSConnect update, check extension compatibility with your GNOME Shell release. The GNOME Extensions page lists each extension version alongside the supported Shell versions.1 This is especially useful on Arch, where updates arrive quickly.
Security and operational notes
Use GSConnect on networks you trust, such as your home or office LAN. Pairing approval is the first barrier against arbitrary local users sending content to the desktop, but it is still sensible to keep remote commands, clipboard sync, and remote input disabled on public Wi-Fi. Remove paired devices that are no longer in use.
Clipboard synchronization deserves special care on development machines where passwords, API keys, and tokens are copied. KDE Connect for Android offers an option to avoid synchronizing sensitive clipboard content.2 Enabling it and limiting sharing permissions per plugin turns a merely working installation into a maintainable one.
Conclusion
The GNOME and GSConnect combination is a comprehensive Android integration layer and a useful local-network bridge for iOS within Apple’s platform limits. On Arch Linux, the essentials are to install the extension carefully from the AUR, use GSConnect alone on GNOME, allow TCP and UDP 1714-1764 only in the appropriate trusted firewall zone, and grant only the permissions your workflow needs. With those pieces in place, routine phone-to-desktop work becomes wireless, account-independent, and unobtrusive.
Sources
Further reading: LinuxConfig’s GSConnect guide for GNOME and It’s FOSS’s introduction to GSConnect.