Configuring OneDriver on BigLinux (KDE Plasma)

Estimated reading time at 200 wpm: 9 minutes

System Profile: BigLinux (Manjaro-based), KDE Plasma Wayland/X11 (on W11 dual-boot), Hardware: Desktop (NVIDIA 3080, Core i7, 32GB RAM), Target: On-demand OneDrive access (FUSE mount) without local storage mirroring. This document records the complete, sequential process used to install and configure OneDriver (specifically the jstaf/onedriver client) on a BigLinux system.

The Context: Microsoft OneDrive is not natively available on Linux. This creates a significant workflow gap for dual-boot systems like mine (Windows 11 / BigLinux). I needed to work seamlessly with my files stored on MS OneDrive online while using Linux, without resorting to the web interface or constantly rebooting to Windows. Onedriver is a Linux built app that will access MS OneDrive from the location where I used OneDrive in Windows. Importantly it will not download gigs of data, like many alternative apps such as Insync. So it’s files on demand.

Crucial Context: This entire configuration was achieved through close collaboration with Grok AI. Going into this, I was unaware of what much of the code meant and was unfamiliar with many of the technical terms involved. This setup could not have been achieved without that expert assistance of Grok AI to navigate the build errors and authentication quirks.

The primary goal was to replicate the Windows “Files On-Demand” experience—accessing files transparently via the file manager without downloading terabytes of data to the local SSD. Why do all this ‘stuff’? Because all my computers will become dual boot. And like ‘why?’. That’s because of how clean and lean Linux is. When I need to use Windows apps, I can just boot back into Windows.

Phase 1: The Initial Approach (AUR Package)

Objective: Install the standard onedriver package from the Arch User Repository (AUR) to get FUSE support quickly.

Why this failed: The AUR package installed successfully but failed to link the binary to the system PATH, leading to “command not found” errors. Additionally, the authentication flow was sabotaged by Microsoft’s aggressive URL redirection.

Steps Taken

1. Mount Point Creation:We selected a mount point on a secondary storage drive to avoid cluttering the home partition. mkdir -p /mnt/S990PRO/OneDriveLnX
2. Package Installation:Attempted to use standard AUR helpers.pamac upgrade onedriver # Alternative attempted: yay -S onedriver
3. The Authentication Struggle:We ran the CLI authentication command to generate the login link, aiming to bypass the GUI popup which often hangs on Linux.onedriver --auth-only --no-browser /mnt/S990PRO/OneDriveLnX
Output: The terminal provided a https://login.microsoftonline.com/... URL.
4. The Redirect Issue:When opening the link in a standard browser window, Microsoft’s server would immediately redirect after login, stripping the essential code= parameter from the URL bar before it could be copied. The browser would show a “removed=true” or a blank “nativeclient” page.

Resolution Attempts:

• Private Windows: We switched to Firefox Private Mode (Ctrl+Shift+P) to prevent cached cookies from auto-completing the login too fast.
• URL Snatching: We had to manually copy the resulting URL immediately before the browser could refresh/strip the token.

Outcome:

While we eventually got the token and the folder structure appeared, the binary issues from the AUR package (missing executable in $PATH) made this installation unstable. We decided to abandon the package manager version.

Phase 2: The Deviation (Abraunegg Client)

Objective: Switch to the abraunegg/onedrive client, which is widely cited as the “standard” Linux client and offers a robust use_device_auth mode that avoids the URL stripping issue.

Why we abandoned it: This client is fundamentally a synchronisation tool, not a network mount. It began downloading files to the local disk, violating the “on-demand” requirement.

Steps Taken

1. Installation: yay -S onedrive-abraunegg
2. Configuration for Device Auth:To bypass the URL redirect hell from Phase 1, we enabled device authentication. File: ~/.config/onedrive/config# Edited config to add: use_device_auth = "true" sync_dir = "/mnt/S990PRO/OneDriveLnX"
3. Execution:Ran onedrive in the terminal. It provided a code and a URL (microsoft.com/devicelogin). This worked perfectly for authentication—no URL snatching required.
4. The Dealbreaker: We ran the sync command: onedrive --synchronize --verbose
Result: The client immediately started creating local directories and downloading actual file data. This risked filling the drive.

Action:

• Terminated process (Ctrl+C).
• Uninstalled the client: yay -Rns onedriver.
• Performed cleanup: rm -rf ~/OneDrive ~/.config/onedrive.
• Security Cleanup: Revoked permissions for “OneDrive for Linux” in the Microsoft Account Portal.

Phase 3: The Solution (Building from Source)

Objective: Compile jstaf/onedriver manually to ensure we have the binary, control the version, and bypass AUR packaging scripts.

Why this worked: It gave us a direct executable that we could link manually, solving the “command not found” error, and restored the FUSE/on-demand capability.

Steps Taken

1. Dependency Management:We ensured all build tools and libraries were present. webkit2gtk is required for the dummy browser window hooks, and fuse2 is needed for the filesystem mount.sudo pacman -S go fuse2 webkit2gtk-4.1 pkgconf git base-devel
2. Cloning and Building:git clone [https://github.com/jstaf/onedriver.git](https://github.com/jstaf/onedriver.git) cd onedriver go build -o onedriver ./cmd/onedriver
Note: The build process took approximately 4 minutes. Some GDK/GTK warnings appeared in the log but were harmless.
3. Verification:Checked the binary was created correctly../onedriver --version # Output: v0.15.0
4. The “NoScript” Attempt vs. Reality:The URL stripping issue from Phase 1 persisted.
   • Attempt: We installed the NoScript extension, hoping to block JavaScript execution on login.microsoftonline.com to freeze the page before redirect.
   • Result: This turned out to be useless. The redirect mechanics were either too fast or required scripts to generate the code in the first place, or the block simply failed to catch the specific refresh trigger.
   • The Actual Fix: It came down to brute-force speed. We had to watch the address bar and hit Ctrl+C the split second the long URL (with the code= parameter) appeared, before Microsoft’s server could refresh the page to the “nativeclient” error. It took a few tries, but manual snatching was the only thing that worked.
   • We pasted this back into the terminal.
5. Initial Mount Test:./onedriver /mnt/S990PRO/OneDriveLnX
Success. Folders appeared instantly without taking up space.

Phase 4: Operational Refinement

Objective: Move the process to the background and silence the logs.

Issue: Running the command in the terminal kept the session open. Using nohup or backgrounding (&) caused the mount to drop unexpectedly.

1. Attempted Background Command:nohup ./onedriver /mnt/S990PRO/OneDriveLnX >/dev/null 2>&1 &
Result: Unstable. The FUSE mount would often disconnect. We unmounted manually to clean up:fusermount -u /mnt/S990PRO/OneDriveLnX

Phase 5: Automation via Systemd (Final Config)

Objective: Create a persistent user service that starts the mount automatically on login, handles restarts if it crashes, and suppresses the verbose inode logs.

Configuration Steps

1. Create Service Directory: mkdir -p ~/.config/systemd/user
2. Create Unit File: We created the file ~/.config/systemd/user/onedriver.service.File Content:[Unit] Description=OneDriver mount for OneDrive # We do not require network-online.target for user services generally, # but the retry logic handles connection delays. [Service] # Important: Point strictly to where we built the binary WorkingDirectory=/home/walker/onedriver ExecStart=/home/walker/onedriver/onedriver /mnt/S990PRO/OneDriveLnX # Restart logic keeps the drive alive if connection drops Restart=always RestartSec=10 # Silence the "inode count" spam StandardOutput=null StandardError=null [Install] WantedBy=default.target
3. Activation: # Reload systemd to see the new file systemctl --user daemon-reload # Enable (start on boot) and Start immediately systemctl --user enable --now onedriver.service
4. Verification: systemctl --user status onedriver.service
Status: Active (running). The folder /mnt/S990PRO/OneDriveLnX is populated and accessible via Dolphin.

Summary & Replication Guide

To replicate this setup for another user (e.g., family member):

1. Prerequisites:
   • Ensure the machine is running BigLinux (or Arch-based distro).
   • Install yay or pamac.
   • Ensure the user has write access to the target mount point (e.g., /mnt/Data/OneDrive).
2. The Critical Path:
   • DO NOT install onedrive-abraunegg (it will fill the disk).
   • DO NOT rely on the AUR package for onedriver (path issues).
   • DO build from source using the Go command in Phase 3.
3. Auth Trick:
   • Forget NoScript: It didn’t solve the issue.
   • Be Fast: When the login completes, the URL bar will briefly flash the full token (starts with code=). You must copy this URL immediately before the page refreshes to the “removed” error. If you miss it, just run the auth command again and be quicker.
4. Maintenance:
   • View Logs: journalctl --user -u onedriver.service -f (Note: logs will be empty if StandardOutput=null is set, edit the service file to debug).
   • Stop Service: systemctl --user stop onedriver.service.
   • Unjam Mount: If the folder looks weird or empty, run fusermount -u [path] and restart the service.

Conclusion: The Value of Persistence

This wasn’t a clean install. It was a series of dead ends—from the AUR package dropping the binary in the wrong place to the “standard” client trying to download the entire cloud to the local drive. The fact that the final solution involved manually compiling code and physically racing a browser redirect script says a lot about the process. It would have been easy to give up when the command not found error popped up, or just accept the storage penalty of the sync client. Instead, we pushed through the build errors and the authentication glitches. It proves that with enough patience (and the right help), you don’t have to settle for a compromise; you can actually force the system to behave exactly how you need it to. We got the on-demand storage, and I learned a hell of a lot about how these packages are put together in the process.