I suppose the choice would be based on the type of searches your users would most likely do.
If the vast majority of searches are simply related to the data in the terminal nodes of your file tree, then you could do this in SQL.
However, if your searches are likely to include looking for children of a specific node somewhere half-way up the tree, then it could be an extremely costly affair for an SQL database and a NoSQL store would be more appropriate.
Also, if your metadata differs from file to file and can’t be standardised as SQL fields, then NoSQL would also make more sense.
Here is how I would do it in SQL: have a table that has a parent field and for each file/directory has a record that keeps track of their parent node. Then you could just search it flatly, and recursively build a path to the specified node as needed.
I would also store the path in a separate field for speed of access. Though it will make reindexing slower, it will dramatically speed up regular lookups.
That being said, I think NoSQL is a better approach in this case and will ultimately work faster.