Cannot search NTFS partition from Activities Overview

I dual boot Windows and Fedora with a shared NTFS partition. My home folders are symbolic links to matching folders on the shared partition, so I can visit them conveniently by clicking the sidebar folders in the Files app. What I don’t get with this setup is working search from Activities Overview (pressing Super and typing to search).

Despite adding the shared partition as a custom search location in Settings, results from it do not show in the overview. If I navigate to the partition in the Files app and search there, it works fine.

Searching for answers led me to look at tracker3. I found various warning and critical messages in the logs so I tried resetting it with tracker3 reset -s then tracker3 daemon -s, but that had no effect.

Environment is Fedora 40, GNOME 46, Wayland, Linux 6.11.3-200.fc40.x86_64

partition details

/etc/fstab

UUID=0C5F6EEC5B15C3A9 /mnt/shared ntfs defaults,uid=1000,gid=1000,dmask=022,fmask=133,x-gvfs-show 0 0

mount | grep shared

/dev/nvme0n1p6 on /mnt/shared type fuseblk (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,x-gvfs-show)
tracker3 log messages

Critical

tracker-miner-fs-3[84897]: (tracker-extract-3:84897): Poppler-CRITICAL **: char* poppler_page_get_text(PopplerPage*): assertion 'POPPLER_IS_PAGE(page)' failed
tracker-miner-fs-3[84897]: (tracker-extract-3:84897): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
tracker-miner-fs-3[84897]: (tracker-extract-3:84897): GStreamer-Base-CRITICAL **: gst_adapter_flush: assertion 'flush <= adapter->size' failed

Warnings

tracker-miner-fs-3[84897]: (tracker-extract-3:84897): Tracker-WARNING **: Task for 'file:///mnt/shared/...' finished with error: Could not get any metadata for uri:'file:///mnt/shared/...' and mime:'application/msword'
tracker-miner-fs-3[84897]: (tracker-extract-3:84897): Tracker-WARNING **: Task for 'file:///mnt/shared/...' finished with error: Could not open:Broken zip file structure
tracker-miner-fs-3[84897]: libpng warning: iCCP: known incorrect sRGB profile
tracker-miner-fs-3[84897]: libpng warning: iCCP: cHRM chunk does not match sRGB
tracker-miner-fs-3[84897]: libpng warning: IDAT: Too much image data
tracker-miner-fs-3[84897]: libpng error: Not a PNG file
tracker-miner-fs-3[84897]: Duplicate property or field node
tracker-miner-fs-3[84897]: libpng warning: iCCP: cHRM chunk does not match sRGB
tracker-miner-fs-3[84897]: (tracker-extract-3:84897): Tracker-WARNING **: Call to gst_discoverer_discover_uri(file:///mnt/shared/...) failed: The stream is in the wrong format.

I have seen a similar report regarding tracker3 not displaying results from an NTFS partition when searching via GNOME Activities.

Does it work when searching from the terminal?

tracker3 search someKeyword

Another possibly relevant information is that while searching from the Files app does search inside indexed files (in which case the Full text match "" icon is being displayed), when using the search function from GNOME Activities, only matching file names are being displayed, but not full text matches.

Yes, tracker3 search test.txt finds both copies I placed in /home and /mnt/shared.

Thanks for the clarification about full text search. I’ve only been testing with filenames.

Try adding actual search locations without symlinks here:

  • GNOME Settings > Search > Search Locations > Custom Locations > Add Location…

If the issue persists, check the output:

gsettings list-recursively org.freedesktop.Tracker3.Miner.Files

Be sure to relogin/reboot to apply the changes and wait until it rebuilds the search index.

Thanks for the troubleshooting suggestions. I have added the shared partition itself as a custom search location as mentioned in my first post above. And just now tried adding subfolders of the partition directly, but there’s no change in search behavior.

Here’s the gsettings output.

$ gsettings list-recursively org.freedesktop.Tracker3.Miner.Files
org.freedesktop.Tracker3.Miner.Files crawling-interval -1
org.freedesktop.Tracker3.Miner.Files enable-monitors true
org.freedesktop.Tracker3.Miner.Files ignored-directories ['po', 'CVS', 'core-dumps', 'lost+found']
org.freedesktop.Tracker3.Miner.Files ignored-directories-with-content ['.trackerignore', '.git', '.hg', '.nomedia']
org.freedesktop.Tracker3.Miner.Files ignored-files ['*~', '*.o', '*.la', '*.lo', '*.loT', '*.in', '*.m4', '*.rej', '*.gmo', '*.orig', '*.pc', '*.omf', '*.aux', '*.tmp', '*.vmdk', '*.vm*', '*.nvram', '*.part', '*.rcore', '*.lzo', 'autom4te', 'conftest', 'confstat', 'Makefile', 'SCCS', 'ltmain.sh', 'libtool', 'config.status', 'confdefs.h', 'configure', '#*#', '~$*.doc?', '~$*.dot?', '~$*.xls?', '~$*.xlt?', '~$*.xlam', '~$*.ppt?', '~$*.pot?', '~$*.ppam', '~$*.ppsm', '~$*.ppsx', '~$*.vsd?', '~$*.vss?', '~$*.vst?', '*.directory']
org.freedesktop.Tracker3.Miner.Files index-on-battery true
org.freedesktop.Tracker3.Miner.Files index-on-battery-first-time true
org.freedesktop.Tracker3.Miner.Files index-optical-discs false
org.freedesktop.Tracker3.Miner.Files index-recursive-directories ['&DOCUMENTS', '&MUSIC', '&PICTURES', '&VIDEOS', '/mnt/shared']
org.freedesktop.Tracker3.Miner.Files index-removable-devices false
org.freedesktop.Tracker3.Miner.Files index-single-directories ['$HOME', '&DOWNLOAD']
org.freedesktop.Tracker3.Miner.Files initial-sleep 15
org.freedesktop.Tracker3.Miner.Files low-disk-space-limit -1
org.freedesktop.Tracker3.Miner.Files removable-days-threshold 3
org.freedesktop.Tracker3.Miner.Files throttle 0

When you’re searching for the same test.txt via GNOME Activities, does it return any results?

Also, when you say, “it finds both copies”, it actually finds one and the same copy[1], but the result is presented twice, given that tracker crawls/indexes both the original path and the symlink. You should disable one of them.


  1. Unless you actually duplicated the test file ↩︎

Searching via GNOME Activities has so far only returned the copy of test.txt that’s in /home/user.

I had actually duplicated my test file. I have not seen tracker3 search find the same file twice in different locations due to a symlink. Only ever one result per duplicate.

tracker3 daemon shows file system miner is idle. I’ve rebooted to be sure.

I found advice to try mounting the other partition inside /home (sudo mount --bind /mnt/shared ~/shared). This also did not get Activities search to find any files in it.

I’m beginning to think this is a bug or a by-design behavior of GNOME.

On one of my Fedora VMs, used for testing purposes, I have created and mounted two disks: one formatted as ext4 and another as ntfs using GNOME Disks utility. These are my findings:

  • neither of the two drives is being indexed by tracker3 (as expected, as neither was added to the list of custom search locations)
  • searching for file names on either of the two drives are being displayed in GNOME Activities’ search results.
  • searching for keywords used in files located in the search paths (e.g. under ~/Documents/) yields results in Files, but not by searching in GNOME Activities.

This brings me to the conclusion that GNOME Activities searches are not connected to tracker3, but only to system apps such as Files etc.

For reference, this is how my test ntfs partition looks like in /etc/fstab:

/dev/disk/by-uuid/37E67D7652A19B17 /media/ntdt auto nosuid,nodev,nofail,x-gvfs-show 0 0

You might want to try playing with the flags, maybe one of them might be the culprit (e.g. nosuid vs setting uid/gid, omitting dmask/fmask permissions etc). You might also want to use the nofail flag, in order to avoid booting into emergency mode if something goes wrong.

1 Like

I’m grateful for both of your help.

I have tried a couple of fstab entries so far, rebooting and waiting for tracker3 file system miner to be idle after each change. None have resulted in finding a test document outside my /home/user folder from GNOME Activities.

/dev/disk/by-uuid/0C5F6EEC5B15C3A9 /mnt/shared ntfs defaults,nosuid,nodev,x-gvfs-show 0 0
/dev/disk/by-uuid/0C5F6EEC5B15C3A9 /mnt/shared ntfs nosuid,nodev,nofail,x-gvfs-show 0 0

(The uid/gid and dmask/fmask flags were in place to get Trash working in the Files app.)

Mike, I created a VM modeled after what you described and that doesn’t get me any results either! :dizzy_face:

As this has been quite a rabbit hole, I looked into alternative setups. I was thinking it would be simpler to have one partition for each OS and a btrfs driver for Windows to access Fedora’s partition as needed. That way my files could just live in Fedora’s main partition. But the only Windows btrfs driver seems to be WinBtrfs, which has serious reliability issues (BSODs, file corruption).