Finder search results are broken aliases

I had the exact same problem and I could fix it by erasing and rebuilding the spotlight index for all network shares affected.

What I did was:

1 - Rebooted my mac.

2 - After a clean boot, I connected to one of my network shares.

3 - Launched Terminal and checked the spotlight indexing status for the share using "mdutil -s /Volumes/networksharename".

If it's on, proceed to step 4.

If it's off, you have to enable it using "mdutil -i on /Volumes/networksharename". Once you do so, it'll start indexing, but I recommend performing the next step anyway.

4 - Still in Terminal, executed "mdutil -E /Volumes/networksharename" to erase and rebuild the spotlight index for that share.

5 - Launched Activity Monitor to check the indexing processes (mds, mdworker, etc). Once they were done, the problem was solved.

Hope it helps 😉

I followed the following advise and it was as simple to fix as turning on the Spotlight Indexing for that drive.

Read the advise I took from another member...

felpzrjJan 23, 2018 3:00 PM in response to paulz42

Level 1 (4 points)

Jan 23, 2018 3:00 PM Re: Finder search results are broken aliasesin response to paulz42

I had the exact same problem and I could fix it by erasing and rebuilding the spotlight index for all network shares affected.

What I did was:

1 - Rebooted my mac.

2 - After a clean boot, I connected to one of my network shares.

3 - Launched Terminal and checked the spotlight indexing status for the share using "mdutil -s /Volumes/networksharename".

If it's on, proceed to step 4.

If it's off, you have to enable it using "mdutil -i on /Volumes/networksharename". Once you do so, it'll start indexing, but I recommend performing the next step anyway.

4 - Still in Terminal, executed "mdutil -E /Volumes/networksharename" to erase and rebuild the spotlight index for that share.

5 - Launched Activity Monitor to check the indexing processes (mds, mdworker, etc). Once they were done, the problem was solved.

Hope it helps 😉

No, if you look at the full instructions as given by felpzrj, the member that originally found this solution, you will realize there are a few variations on the mdutil command given. The one with the -E is to erase the index and is recommend to have a "clean slate" and avoid some possible corruption. It is harmless as you are going to create a new, fresh index executing the following step

"mdutil -i on /Volumes/networksharename" without the quotation marks and replacing networksharename with the actual name of your share.

This command turns indexing on and if no index exist, it creates and starts a new one.

The original member that found the solution is felpzrj and he recommended (not necessary, just in case you are a bit OCD) that as a final step #5, and I quote, "

5 - Launched Activity Monitor to check the indexing processes (mds, mdworker, etc). Once they were done, the problem was solved."

Hi I had the same problem! I managed to solve with the following procedure:

To fix this issue, create the following directory as root:

sudo mkdir -p / private / var / db / Spotlight-V100 / Volumes /

And then re-enable Spotlight indexing of that Volume:

sudo mdutil -i on / Volumes / name_of_your_volume

subsequently I managed to enable the search for spotlight on the network path!

Before any attempt to enable it using mdutil -i on / Volumes / myvolumes the result was always indexing disabled!

now if I look for a file and open it, it opens correctly!

Installed osx version: 10.13.3

lets hope this make a difference take a look a the second line, try it out and lets see if it work.

About the macOS High Sierra 10.13.3 Update

This update is recommended for all macOS High Sierra users.

The macOS High Sierra 10.13.3 Update improves the stability and security of your Mac and is recommended for all users.

This update:

• Addresses an issue that could cause Messages conversations to temporarily be listed out of order
• Resolves an issue that could cause your Mac to stop responding when connected to an SMB server

See Apple Security Updates for detailed information about the security content of this update.

Learn how to get this macOS update.

Published Date: Jan 23, 2018

This is working for me. I had to use:

"sudo mdutil -E /Volumes/sharedvolumename", instead of "mdutil -E /Volumes/sharedvolumename", but this has now indexed the shared drive.

Also, the index is updating itself for files created since I performed the original indexing command files - the Search Results are including these new files. This indicates to me that indexing is now ongoing.

Hope this helps anyone else experiencing this issue.

All the best.

I followed these steps (but added in "sudo" before mdutil) - from further up the discussion thread:

1 - Rebooted my mac.

2 - After a clean boot, I connected to one of my network shares.

3 - Launched Terminal and checked the spotlight indexing status for the share using "mdutil -s /Volumes/networksharename".

If it's on, proceed to step 4.

If it's off, you have to enable it using "mdutil -i on /Volumes/networksharename". Once you do so, it'll start indexing, but I recommend performing the next step anyway.

4 - Still in Terminal, executed "mdutil -E /Volumes/networksharename" to erase and rebuild the spotlight index for that share.

5 - Launched Activity Monitor to check the indexing processes (mds, mdworker, etc). Once they were done, the problem was solved.

I'm no expert, so if this doesn't work for you, I don't know what else to suggest.

Cheers.

Two possibilities:

Erase any index that may exist and is corrupt by issuing the mdutil -E /Volumes/companydata2 command and then repeat the mdutil -i on /Volumes/companydata2 command to turn on indexing.

The other possibility, repeat the above commands BUT add the sudo command before it to gain higher privileges like this:

sudo mdutil -E /Volume/compnaydata2

sudo mdutil -i on /Volume/companydata2

The first time you issue the sudo command it will ask for your password (admin password). It DOES NOT type as you enter the password. That is normal and may confuse you. Just type it and press <return> to execute.

Good luck!

I opened a case with Apple Enterprise Support about this (see my previous post in the thread). The engineer on my case confirmed that it should be fixed in 10.13.4. Thanks for letting us know that the Beta fixed it already.

Hi

Just to say now I have downloaded the latest update from App Store 10.13.4 it has now fixed the issue.

Pleased it's done... Such a shame Apple took over half a year to fix.. Cleary not an OS to rely on for Business or critical home use at the present time.

Hi Paul,

I've experienced a similar problem with my Synology, but only with the "home" shared folder that actually redirects to /volume1/homes/username. If I mount homes/username directly, then I can open spotlight results correctly. I spoke with Synology support and they indicated this is a known issue with macOS but they have no intention of fixing it. The confusing part is that Synology support indicated that the problem is with network locations called "home" rather than with any other details of how they implemented the "home" network volume.

This problem is not only when operating on spotlight results in the "home" folder, but anytime Finder tries to alias anything in "home", e.g. when working with file/folder aliases in AppleScript.

Unfortunately, Synology sounds uninterested in a fix for this problem.

Here's my conversation with Synology support:

Them:

...

This is likely related to other known issues with the home directory in regards to the macOS. Because of the way that the macOS treats the home directory there are some network features that simply won't work.

For example Microsoft Office for Mac can't access files in the "home" shared folder.

Unfortunately, the only work around in cases like this is to simply not use the "home" shared folder.

Me:

... The KB article you linked to says '...Microsoft Office 2011 for Mac has problems accessing files stored in any network shared folder named “home”’. Regarding the “…any network shared folder named “home…” part, is it really the name of the network volume that is causing the problem? If that’s the case, then a custom name for each user’s “home” would suffice as a workaround, right?

Has Synology looked deeper into this issue?

...

Them:

In cases like this, yes the issues is simply the name of the network volume. You can create your own Custom Shared folders and name that whatever you'd like, and they should work. However, there is no way to change the name of the default home/homes shared folders.

Work around - go to the App Store and install EasyFind. That successfully finds files in my large SMB file share and I can open the files no problem.

This issue seems to be resolved in the upcoming update. 10.13.4 Just tested with the Public Beta.

10.13.4 fixed this problem for me too.

FWIW, I have done some testing after hitting the same issue. I will state up front that I do not have this problem when searching a share that is serve by another Mac running Sierra. My High Sierra client has the "broken alias" issue when talking to NetApp ONTAP (Proprietary), FreeNAS 11.0U3/4 (Samba 4), & Windows 10 Fall Creators Update. All three of these work without any noticeable issue when the client is running Sierra.

garz75, thanks for opening a ticket. I look forward to your updates.