OneDriveGUI rewrites your OneDrive config comments when it imports it

The GUI manages the client, it does not replace it

The relationship to the underlying OneDrive client is the first thing to get right, and the README states it as a requirement.

OneDriveGUI is a GUI for the Linux OneDrive Client, with the client being the separate abraunegg project, and the first item in the running and installing section is a warning that you must ensure the latest version of OneDrive for Linux is installed, following the install instructions for your distribution.

So this is a front end over a client you install separately. It configures it, starts it, watches it and shows its progress. It is not a sync implementation of its own, and installing the GUI does not give you a working OneDrive setup on a machine without the client.

That distinction also explains the compatibility line. The minimum supported OneDrive client version is v2.5.11, and you will be shown warnings if your client is not up to date. A warning rather than a refusal means the GUI will run against an older client and may misconfigure it, which is a decision worth understanding before you point it at a machine with real files in it.

The multi-account story is the substantive addition. The feature highlights list management and configuration of multiple OneDrive accounts, asynchronous real-time monitoring of multiple accounts, and progress monitoring of multiple simultaneous file transfers. A single-account user gets a nicer way to edit one configuration file; a multi-account user gets something the client alone does not offer.

The remaining features are quality-of-life items that each solve a specific irritation: a setup wizard for profile creation and import, auto-sync on GUI startup, a GUI-based login process instead of a terminal prompt, a system tray icon where the desktop environment supports one, starting minimised to tray or dock, tooltips explaining what each client option does, and input validation to prevent configuring incompatible client options.

Importing a config file rewrites it

The additional notes section contains the two lines an adopter should read twice, and neither is in the feature list.

The first: when importing a OneDrive config file, all comments will be removed. The second: if multi-line options `skip_file` and `skip_dir` are used, they will be consolidated into a single line.

Neither is a bug. A configuration file you generate through a wizard or rewrite programmatically has no room for the annotated comments a hand-written file accumulates, and the multi-line form of those two options has to be flattened to be re-emitted. But the effect is that the file on disk after an import is not byte-identical to the one before it.

Combined with the two backup warnings elsewhere in the README, the sequence to follow is clear. The README asks you to back up your OneDrive config files before importing them to the GUI, and separately asks you to back up your data before use to prevent accidental file deletion due to OneDrive misconfiguration.

That second warning is the serious one. A misconfigured client can delete or move synced files, and a sync client operating on your real documents is not something to experiment with. The README pairs it with an explicit no warranty statement, which is unusual to see written plainly and worth taking at face value.

There is a related feature that mitigates the risk: a prompt for re-sync authorization to prevent unexpected data loss. That means the GUI asks before a re-sync that could remove data, which is a guard rail rather than a guarantee.

The config locations are also worth writing down. The list of managed profiles is stored in `~/.config/onedrive-gui/profiles`, and you can manually rename a profile or its path there. Newly created OneDrive config files go into `~/.config/onedrive/accounts/<profile_name>`, which is the client's own multi-account layout.

Three install routes, and FUSE2 is the AppImage gotcha

Distribution is three routes, and each has one thing that catches people.

The AppImage is the primary route. Download the latest `OneDriveGUI-*-x86_64.AppImage` from the release assets, make it executable and run it:

chmod +x ./OneDriveGUI-<**version**>-x86_64.AppImage

The AppImage has two documented rough edges. Users of Ubuntu 22.04 and later may need to install FUSE2 with `sudo apt install libfuse2`, which is the usual AppImage-on-modern-Ubuntu problem. And the AppImage still requires an external browser for authentication, which the README lists among the known limitations rather than burying.

The AUR route exists as `onedrivegui-git`, maintained by someone named Integral. The `-git` suffix means it tracks the repository rather than a release, so it moves with the default branch.

Running from source needs Python 3 and pip, then:

git clone https://github.com/bpozdena/OneDriveGUI.git
cd OneDriveGUI

then dependencies:

python3 -m pip install -r requirements.txt

and the launch command, which is inside a `src/` directory:

cd src/
python3 OneDriveGUI.py

To detach the GUI from the terminal:

cd src/
nohup python3 OneDriveGUI.py > /dev/null 2>&1 &

The entry point being `OneDriveGUI.py` inside `src/` rather than a package with a console script is worth noting, and the nohup form is the documented way to run it as a background application rather than a session process.

Packaging is scripted in the repository, with `build_appimage.sh` and `build_appimage_docker.sh` plus an `AppImageBuilder.yml`, so the container-based AppImage build is reproducible from the tree.

requirements.txt splits on Python 3.8 and pins urllib3 below 2

The requirements file is six lines and one of them is a decision you will notice on a fresh install.

PySide6_Essentials==6.2.2.1; python_version <= '3.7'
requests==2.27.1; python_version <= '3.7'

PySide6_Essentials==6.11.1; python_version >= '3.8'
requests; python_version >= '3.8'
urllib3<2.0

For Python 3.7 and older you get an old PySide6 and an exact `requests` at 2.27.1. For Python 3.8 and newer you get PySide6 6.11.1 and unpinned `requests`. So the supported floor is Python 3.8, and the 3.7 line exists only so the file resolves rather than failing, which is a courtesy rather than a support commitment.

The `urllib3<2.0` line has no environment marker, which means it applies unconditionally. urllib3 2.0 was a breaking release, and pinning below it is the kind of constraint that exists because something in the chain has not caught up yet. If you are installing into an environment that already has urllib3 2.x, this line will downgrade it, and if you have other packages depending on 2.x you will get a conflict.

That is worth knowing before you run the install command in a system Python. It is one of the strongest arguments for the AppImage or the AUR route, where the dependency resolution happens in an isolated environment instead of yours.

The Qt binding choice is `PySide6_Essentials` rather than the full PySide6 package, which is the smaller distribution. The project uses only the essentials modules, which is why the size of a Qt application here is reasonable.

Logging is mentioned in the additional notes with the save path left as empty backticks, which is a documentation gap rather than a configuration: the README says debug logs are saved in a location it does not name, and that logging behaviour can be changed in the GUI settings.

Wayland limitations and what the GUI actually does with your data

The known limitations list is short and all Wayland-related except one.

No window shadows for Wayland sessions. No window icon when using the AppImage on Wayland. And the AppImage still requires an external browser for authentication. The README also points at the issue tracker for other reported limitations, which is the honest framing for a project where the desktop environment matrix is not fully covered.

Those are cosmetic rather than functional, with one exception. If you are on Wayland, the tray and dock behaviour is the feature most likely to differ from what you expect, and start-minimised-to-tray is explicitly listed as a feature conditional on your desktop environment supporting a system tray. On a compositor without one, the window simply appears.

The feature list also includes import and management of SharePoint Shared Libraries, which is a OneDrive client capability surfaced through the GUI rather than something this project implements. That is a useful thing to have in a front end, and a reminder that the feature list spans two projects.

On the data-handling side, the two warnings already quoted are the whole story: back up your config before importing, and back up your data before use because OneDrive misconfiguration can delete files. Combined with the no warranty statement, the reasonable reading is that this is a careful front end over a client that can be destructive when misconfigured, and the author has said so rather than leaving it to be discovered.

Icons are attributed to Icons8, which is the sort of detail worth checking if you redistribute the application, since icon licences are separate from the project licence.

Editorial conclusion

OneDriveGUI fits a Linux user with more than one OneDrive account who wants the client managed from a window rather than from configuration files, since multiple accounts and per-profile options are the features the project adds over the client itself. Do not import your existing configuration without reading it first, because the import path rewrites the file and removes comments and consolidates multi-line skip options. Verify first which OneDrive client version you have, since v2.5.11 is the stated minimum and anything older will show warnings about being out of date.

Frequently asked questions

Official sources

1. bpozdena/OneDriveGUI on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases