When I installed Fedora and started searching bu Super key, it can’t find any file from second drives.
I mounted them inside /mnt and /home with no effect. I added the drive to search settings, but still the same issue. It only search for the drive name, not any of subfolders.
I also searched using tracker3 in terminal and it doesn’t give me any search, too.
Maybe because those drives are considered removable devices, and Tracker does not index those by default. You can check the output of:
gsettings get org.freedesktop.Tracker3.Miner.Files index-removable-devices
It is probably set to false. If so, either change the setting to true (probably not the best idea, as this would make also USB drives to be indexed), or, better yet, tell the system that the second drive is not removable media (I think that should work by adding it to /etc/fstab).
Okay, I added this by mounting the drive by Disks application. I mounted it to subfolder in home and added t to bookmarks and search settings. It still not shwing in overview search (Super key search). But, when I use terminal tracker3 command, it works fine and find any file.
So, what can be the issue??
It’s interesting that filesystem search doesn’t work for removable devices. I’m not immediately sure why that would happen. The code to generate the search query in Nautilus is here and I don’t see any sort of “ignore removable devices” clause
Thanks for replying.
The issue is not in Nautilus, it’s in the overview search (super key search). When I search any file inside a second drive, it’s not shown. But, inside Nautilus and command line (tracker3), the entire drive is searched fine. I mounted the drive in home directory and added it to search settings.
I had a similar issuewith encfs encrypted mounted folders that I couldn’t get to be searched by overview search no matter what.
I like the overview search and all these fancy search providers, but in the end I decided that a search that does not reliably finds my stuff is of no good use. Currently, I only use search for starting and switching to apps.
For searching files I use fsearch.
That’s not an ideal solution, but at least it works.
There’s plenty of room for improvement in how the overview search is implemented. There was some discussion of this here. That’s quite a big proposal and needs people to organise, fund and develop the changes.
In case you didn’t make the modifications yourself, it seems that those folders were added automatically (I assume as a result of creating the mount points in fstab). This means mounting under Documents probably wasn’t necessary.
It is also not clear to me why the old mount point (/home/minawaheed/Drives/Data) has not been removed from the list of recursive directories to be indexed (unless you kept the old mount point as well).
You might want to install dconf-editor (if not already installed) and look at the settings under /org/freedesktop/tracker/miner/files/. There might be hints on why those files under the mount point are not being indexed.
I ran out of ideas why you’re having this issue. I think you’ll have to investigate further yourself. You might want to check all the keys in dconf under /org/freedesktop/tracker/miner/files/ (not just the one you took the screenshot of), maybe check the status of tracker3 (with tracker3 status), your mount points (with findmnt --real), test tracker3 by searching for different file names and types etc. If it still seems a bug, you could report it with the appropriate project.
For what it’s worth, I have tried to recreate your scenario in a virtual machine (by attaching a secondary disk, formatted as ext4), and noticed the following:
The test files from the secondary disk were not indexed when mounted outside of user’s home directory;
The test files started getting indexed after moving mount point under /home/<user>/;
However, as opposed to your experience, the mount points were not added as values in the dconf key /org/freedesktop/tracker/miner/files/index-recursive-directories. I am running Fedora 41 Beta.
May be this is the issue?
My drives are ntfs format. Can this affect the search? But, if yes, it should also affect the command line search and Nautilus.
Maybe, I am not sure though. You can test if a file from the ntfs partition is tracked by running tracker3 status /path/to/one/of/your/files. You could also create a Linux native partition (e.g. ext4) to check if there is any difference in indexing.