I am running ZimaOS 1.5 on my Zimacube updated with the Tesla P4.
AI search appears to work for two of my storage solutions, but not for any of the others.
My storage consists of (which you can see on the attached pics):
ZimaOS-HD
Main-Storage (a four disk RAID5 array)
FastRAID (a two disk RAID0 array)
SSD1-Storage (2TB SSB)
My dropbox storage
If I search for a file, ai search appears to only search the top two in this list - ZimaOS-HD and Main-Storage. It does not find files that are known to be on the other/lower three in the list.
This is a shot of a “Search All” in the Movies directory of the SSD1-Storage volume. It does not find the copies of these movies there:
This is a shot of searching only in the Movies folder of the SSD1-Storage volume. It does not find files that are obviously there:
The same will occur if I attempt to search for a file on any of the final three volumes in the list above. The file will appear in the search if I have done a “search all” and the file exists on any of the upper two volumes in the list, but not on any of the lower three volumes of the list.
Perhaps I need to somehow give ZimaOS permission to index these other volumes? Or maybe I need to force indexing on these other three volumes?
Anybody have any ideas? Thanks in advance.
Pat
1 Like
Is there a config file that keeps track of the volumes to be indexed?
Interestingly. I found a file in /etc/casaos named zimaos-serach.conf (search was misspelled as serach). I renamed it to zimaos-search.conf. To be clear, I did not initially misspell the filename - must have occurred with an update. This had no immediate effect. I guess we’ll see.
@Zima-Giorgio - any suggestions?
1 Like
Copy it. The team will investigate it.
1 Like
@Zima-Giorgio
Ok so when I went to get the file contents for you guys, I noticed something interesting. I had previously just renamed the file from zimaos-serach.conf to zimaos-search.conf using mv (mv zimaos-serach.conf zimaos-search.conf). It appears that the system has regenerated a file named zimaos-serach.conf. See pic:
Both zimaos-search.conf and zimaos-serach.conf contain the following lines:
[app]
LogPath = /var/log/casaos/
LogSaveName = zimaos-search
LogFileExt = log
[common]
[app]
LogPath = /var/log/casaos/
LogSaveName = zimaos-search
LogFileExt = log
[common]
DBPath = /var/lib/casaos
RuntimePath = /var/run/casaos
Search is still not fully functional as noted above.
Thank you for any help.
Pat
It would make alot of sense if that file had a section [Index_paths] where we could define what volumes and directories to be indexed.
That’s actually a really interesting find, and it explains a lot about what’s going on under the hood. It looks like the ZimaOS indexing service is hard-linked to that specific configuration filename, even with the typo. When the file was renamed, the system immediately regenerated it because the search daemon expects that exact name and path.
So this confirms that the search system isn’t reading from user-editable configs or external settings. It’s running from an internal service that maintains its own configuration and will recreate it whenever it doesn’t match what the daemon expects.
In other words, the behaviour isn’t a bug with your setup, it’s just how the indexing service is currently designed. The regeneration shows that the process is self-managed, which means manual adjustments or renames won’t actually change how search behaves or what volumes it indexes.
For now, this reinforces that the limited indexing coverage isn’t due to configuration issues but a system-level limitation. It’s likely hardcoded to only index the default or primary volumes. Hopefully, a future ZimaOS update will open this up with options to manually trigger re-indexing or add specific drives to the AI search scope.
1 Like
Agreed. This was what I’d hope I’d find when I started my config file hunt.
Thanks for your feedback, we will fix the typo in the most recent release
will we be able to realistically expect zimaos search to include all volumes that are mounted in the search at some point?
Are you referring to global search? This is a feature expectation
