I’m not sure if this should be a bug report or a feature request. I suppose I lean toward feature request but I’d appreciate feedback.
Product: frameworks-baloo
Version: 6.30.0 (Fedora 44)
Baloo excludes FUSE-based network filesystems from indexing, with no way to override it. This affects filename indexing, not just content. The folder shows as configured correctly, but is never actually crawled, with no error anywhere.
Environment:
- Fedora 44, Plasma 6, kf6-baloo 6.30.0
- rclone mount of a Box.com remote, filesystem type reported as fuse.rclone
Steps to reproduce:
- Mount a remote:
rclone mount remote:path /local/mountpoint
balooctl config add includeFolders /local/mountpointbalooctl config set contentIndexing false (to rule out content extraction as a variable)balooctl check, restart kde-baloo.service- Wait several days of continuous uptime (confirmed via journalctl: no suspend/resume in that window)
Expected: Baloo crawls and indexes the folder’s filenames.
Actual:
- System Settings shows the folder as “Not running, 0% complete” indefinitely.
balooctl status file count barely moves (888 to 889 over ~71 hours).- Real tree size, via
rclone lsjson -R --fast-list, is 200,000+ entries; Baloo never approaches this.
baloosearch6 finds nothing for untouched files deep in the tree, confirming the index itself is empty there. Dolphin/KRunner do eventually return results, but that’s a separate live filesystem crawl fallback, not Baloo’s index.- With debug logging on,
kde-baloo.service explicitly logs the mount by type at startup:
Adding "fuse.rclone/home/path_to_folder" type: "fuse.rclone"
This points to the StorageDevices/removable-media gating mechanism (per Baloo’s own class docs), separate from includeFolders/excludeFolders and not exposed anywhere in baloofilerc or balooctl config.
Ruled out: content-indexing cost, suspend/sleep, database corruption (reproduced after full purge), path misconfiguration.
Likely origin: this is probably intended behavior from bug 343437 (“Do not Index NFS,” RESOLVED FIXED), where indexing network shares was deliberately disabled after it overloaded a shared NFS server. I suppose that’s a reasonable default for that case.
But not having an explicit opt-in override, a config key or per-folder toggle, letting a user index a specific folder despite its network/FUSE classification, for cases like a personal single-user mount where the original NFS-server-load concern doesn’t apply seems silly. I can use a third-party tool like fsearch but I want to use krunner / dolphin.
yeah baloo hard-skips fuse.* network mounts and includeFolders doesnt override that. feature request on bugs.kde.org under frameworks-baloo is the right home (call out StorageDevices / removable gating + fuse.rclone)
workarounds ive used:
-recoll or fsearch pointed at the rclone mount for filename search
-rclone mount with --vfs-cache-mode full into a local cache dir and let baloo index that path instead
-dont force baloo onto the live fuse mount, it just sits at 0%
Dolphin/KRunner live crawl is separate so search can still “work” while the index stays empty
My current workaround is a python script to grab the index from rclone and then, one by one, force an index on each individual file, and put the script on a timer. This is not an ideal solution.
Baloo just isn’t designed for t hat - but it might be worth looking at Recoll, which doesn’t hard-block network or virtual filesystems.
inotify limitations are a problem for Baloo on networks, you can get around that by settingiRecoll using batch cron jobs or systemd timers to re-index periodically, though not live the way Baloo does.
You should only really consider filename indexing - fzf and fd will bypass indexing entirely.
- To find files by name, use
plocate with scheduled updatedb or use fd
Good evening,
Can you clarify what you meant by “baloo just isn’t designed for that”. I’m not sure what the referent is.
I maybe wasn’t clear in my post, but I am only considering filename indexing, not content. I am not interested in content indexing on the fileshare, but I make extensive use of filetags (meta tags in the filename) and so indexing by filename is very important for me, much more so than content indexing. I can appreciate why content indexing would be bad for network shares.
I am not interested in CLI-only commands. I need integration with desktop tools because that is how I manage files.
Ok, so a self-imposed limit to an arbitary barrier has now elevated it to the level of solving the desktop integration issue - which is a much deeper problem requiring much more advanced solutions.
Misunderstanding Baloo is a core issue here - Baloo is intentionally designed to AVOID network/FUSE mounts because FUSE filesystems often introduce problems - they often lack standard inotify file-change notifications, and attempting to force it is going to cause bigger problems and high CPU usage.
Baloo works well when used as designed.
Recoll, FSearch, Krunner extensions provide interfaces that can handle scheduled indexes or fast searches without relying on Baloo - that would be my choice of action.
I don’t believe you know my situation well enough to decide whether the limitation is “self-imposed”, and that critique is well outside the scope of the question.
I am not so sure that I misunderstand baloo; according to the bug report I referenced, the stated reason network share support was removed was to prevent the indexing from hammering the NFS server, not anything to do with inotify. This doesn’t seem to be a technical limitation but rather a choice. I’m sure you’re correct about inotify but there do seem to be technical workarounds that perhaps the developers feel are not worth the trade-offs.
As for it “working well when used as designed”, I’m sure we can all appreciate the truth of that, but surely things can always be made better. 
Thank you for the software suggestions; I’ll look into them.
To clarify: It’s a simple matter that there is no “opt-in” override.
Without filesystem events, Baloo would have to recursively poll the entire FUSE mount periodically, which creates the exact server-hammering issue the safety check was designed to prevent.
The reason alternatives like Recoll or FSearch are often recommended here isn’t to push CLI tools for the sake of it, but because:
-
They are built around batch/scheduled indexing, which fits remote and FUSE filesystems much better than Baloo’s event-driven model.
-
Many of these tools do offer GUI integration - Recoll has a Dolphin KIO slave (recoll://) and a KRunner plugin, giving you desktop search integration without forcing Baloo to continuously scan remote FUSE mounts.
You’re right that things can always be improved, and opening a feature request on bugs.kde.org (suggesting an opt-in flag with explicit warning about polling overhead) is definitely the right path forward if you’d like to see Baloo support this natively.