udiskie automounts removable media on Linux without taking over udisks2

udiskie is a userspace front-end for udisks2

udiskie does not implement a disk stack of its own. The project describes itself as a udisks2 front-end that lets you manage removable media such as CDs or flash drives from userspace, and the repository is written in Python with a GTK classifier for X11 applications. That framing matters for anyone deciding whether to adopt it. The mounting, device detection, and privilege handling stay with udisks2, the freedesktop daemon that most Linux desktops already run, and udiskie supplies the layer a person actually touches: the automatic mount on insertion, the desktop notification, the tray menu, and the ability to act on a drive manually from a shell.

The consequence is that udiskie is additive. It does not ask you to replace udisks2, disable the distribution's own automounter, or mount filesystems with root privileges from a Python script. The trade-off is that udiskie cannot fix a system where udisks2 itself is misconfigured, because it only reacts to what that daemon reports. Everything udiskie knows about a drive arrives through the udisks2 interface, and the project also points readers to the UDisks2 API and the PyGObject APIs for the underlying details.

One daemon and four console entry points

The packaging metadata is more informative than a README feature list, because it shows the shape of the tool. The script entries declare a daemon named udiskie and three helpers: udiskie-mount, udiskie-umount, and udiskie-info. In other words, the interactive behaviour and the scripted behaviour are separated. The daemon is the part that watches for devices, shows the notification, and owns the tray icon, while the three helpers are the manual path for a drive you did not want mounted, or for a drive that arrived while the daemon was not running.

The command line tools are listed among the project features as tools for manual un- and mounting, and the dependency list includes docopt, which is the argument parser used for command line interfaces written in Python. The setup file also installs shell completions, with the completions directory in the repository holding zsh and bash entries that are copied into share/bash-completion/completions and share/zsh/site-functions at build time. For a power user, that is the detail that makes the helpers pleasant to live with: udiskie-umount and friends get tab completion in the shell.

LUKS unlocking pulls in keyutils and a udisks version floor

Encrypted USB sticks are the reason many people want a userspace automounter at all, and this is where udiskie has to be precise about versions. The feature list names LUKS encrypted devices, unlocking with keyfiles, and password caching, and it attaches a condition to two of them: keyfile unlocking requires udisks 2.6.4, and password caching requires keyutils.

Those are not footnotes. A machine running an older udisks will mount the encrypted volume but fail at the unlock step, and the failure will look like a udiskie bug rather than a version mismatch. The keyutils dependency is a separate package that is not pulled in automatically by a Python install, so on a minimal system the password cache path can be silently unavailable even when everything else works. If your workflow involves several encrypted drives and unlocking them by typing a passphrase each time, check for keyutils on the target machine before you install anything, and confirm the udisks version in the same session. The stack, in other words, ends with a C library and a daemon version, not with a Python wheel.

Configuration is YAML and the shipped example is the reference

udiskie keeps its settings in a YAML file, and the dependency list includes PyYAML, which is what makes that format work without extra plumbing. The repository carries an example folder with a file named config.yml and a file named udiskie.service, and the service file naming is the giveaway about how this is expected to run in practice: as a per-user service tied to the desktop session, not as a system daemon started at boot like udisks2 itself.

The visible documentation does not enumerate the configuration keys, so treat the example file as the reference rather than assuming option names from other automounters. What the project does state clearly is that every feature can be individually enabled or disabled, which includes the automount behaviour, the notifications, and the tray icon. That granularity is the point of the YAML file: a user on a machine with no desktop session, or a user who dislikes the pop-up notification, can turn that part off without abandoning the whole tool. Read example/config.yml before you wire the service into a session, since the file in the repository is more authoritative than anything a blog post would guess.

Building a translation from the lang folder

The clearest worked example in the project is the translation workflow, and it also shows how to run udiskie against your own files. Translation sources live in a lang subfolder, and the pot file is udiskie.pot. To start a new language, the project tells you to find the locale name for your language, for example es_ES for Spanish, and create the file from the lang folder with:

cd lang
make es_ES.po

To test your edits without installing anything, the README asks you to set the text domain directory and locale, compile the catalogue, and start the daemon:

export TEXTDOMAINDIR=$PWD/../build/locale
export LANG=es_ES.UTF-8

make mo
udiskie

The compile step is wired into the packaging, where the build command is subclassed to add a build_mo subcommand that calls msgfmt to turn each lang/*.po file into build/locale/<lang>/LC_MESSAGES/udiskie.mo. The setup code wraps that call in a try/except that logs a warning instead of failing the build, so a missing gettext toolchain only costs you translations, not the install. That same leniency is the single most useful thing to know about the project for contributors: an untranslated or uncompiled locale degrades to English rather than breaking the daemon.

Where udiskie is the wrong answer

Three cases rule udiskie out. First, Python 2 and udisks1 support has been removed, and the project says so plainly in a note: anyone who needs that combination should check out the 1.7.X releases or the maint-1.7 branch. If your distribution still ships udisks1, udiskie is a maintenance project on the 1.7 line, not something you upgrade. Second, headless systems have no use for the tray icon and no session to attach a per-user service to, and the automount behaviour of udisks2 plus a cron job or a small script is usually the better fit. Third, udiskie is a Python application that depends on PyGObject, which means the system needs the GTK introspection stack and its typelibs present, not just a Python interpreter.

There is also a documentation limit worth stating plainly. The visible README points to a wiki with Usage, Installation, Debug Info, Troubleshooting, and FAQ pages, and it links a man page in the doc folder, but the project keeps no GitHub releases, so version tracking happens on PyPI and in the CHANGES.rst file at the repository root. When you upgrade, PyPI and that changelog are where the history lives.

MIT licensing and a two-author maintenance surface

The licence is MIT, with the licence text in the COPYING file at the repository root and the licence-files entry pointing at that same copy. That is a permissive licence with no obligation on a commercial deployment beyond keeping the copyright notice, and the same MIT terms apply whether you install from PyPI or vendor the source. This is a licensing observation rather than legal advice, and it does not cover the separate licences of the components underneath: udisks2, keyutils, and PyGObject each carry their own terms.

The maintenance surface is small and visible. The packaging metadata names two authors and lists a maintainer, and the last push to the repository was on 2026-10-14. Two long-running maintainers with a public issue tracker and a wiki for troubleshooting is a reasonable profile for a project whose job is small and whose upstream contract is the freedesktop UDisks2 API. Translations are handled through a Weblate interface that the project itself calls experimental, with the po files in the lang folder as the fallback path.

Editorial conclusion

udiskie fits a Linux desktop where a user plugs in flash drives and expects them to appear, and it is a poor choice for a headless host or for anyone still on udisks1 or Python 2. Before adopting it, check the two dependency floors that bite in practice: keyfile unlocking needs udisks 2.6.4, and password caching needs keyutils, and the tray icon itself assumes a GTK session. Also confirm that your distribution's PyPI build of udiskie matches the udisks2 version already installed on the machine.

Frequently asked questions

Official sources

1. coldfix/udiskie on GitHub
2. Issues
3. License: MIT
4. README