I have a little NAS at home which makes some volumes available through AFP. This all worked great. Until I shut it down for a while and reconnected it recently.

I can see the device on the network and I can open it and select a share. But when I try to mount the share, I get the following error:

"The operation can’t be completed because the original item for “Foo” can’t be found"

I think this is because my little NAS changed to a new IP and OS X somehow cached the original (alias?) somewhere.

The fact that I can successfully open these shares from another Mac, which had never seen these before, confirms that I think.

Does anyone know where this is potentially cached? Is there anything I can reset or throw away to get past this error?

  • BEST ANSWER to solve this mess is here : apple.stackexchange.com/questions/441086/…
    – Dan PUIU
    Commented Mar 5, 2023 at 18:40
  • @DanPUIU Not necessarily. Didn't help the problem at all for me, I already had smbd added to Full Disk Access. I even removed it and re-added to to make sure. No dice.
    – John Smith
    Commented Oct 25, 2023 at 18:48

28 Answers 28


Apparently this problem can occur for many different reasons. In my case it was solved by re-launching the finder. A description and solution for this was at http://www.cnet.com/news/fix-shared-computer-not-found-in-finder/ .

To fix this problem, you simply need to relaunch the Finder, and it will re-populate the list of shared devices. To do this, you can do one of the following:

  • Hold the Option key and right-click the Finder icon in the Dock, then select Relaunch.
  • Press Option-Command-Escape or choose Force Quit from the Apple menu, then select the Finder and click Relaunch.
  • Log out and log back in to your user account.
  • 44
    Relaunching the finder worked for me too. Apple menu (top left) -> Force Quit -> Finder -> Relaunch.
    – cgenco
    Commented May 19, 2016 at 21:13
  • 2
    Same prob here on Sierra, annoyingly now it also closes the finder window after dismissing the alert. Relaunching Finder allowed the network volume to mount again.
    – malhal
    Commented Jan 7, 2017 at 13:59
  • 3
    WFM too however it's a pain in the ass, I almost always have o restart finder in order to be able to connect to shares.
    – TCB13
    Commented Apr 19, 2017 at 17:32
  • 2
    Ya can't use NFS 'cuz Apple doesn't like it any more and SMB is a pain in the derrier. It's like Apple wants you to use a pure Apple shop? For me, not permissions and not stale connections. Must be something else with the exact same error message. "Lovely."
    – Bruce
    Commented Oct 2, 2017 at 17:57
  • 2
    Edit/addon: SMB uses its own password mechanism, because of_course it does.
    – Bruce
    Commented Oct 2, 2017 at 18:04

Ok so I am going to answer my own question. In my case the solution turned out to be really 'simple'.

I looked at another Mac and I noticed that the /Volumes directory had different permissions. On the problematic Mac it was set to drwxr-xr-x and on a recently installed Mac it was drwxrwxr-x.

So I fixed my problem with:

sudo chmod 775 /Volumes

(You can also do that in the Finder of course, via Get Info)

Problem solved. I can now mount any file share again.

  • My /Volumes permissions were the same as your problematic Mac, so I ran your chmod 775 but in my case that did not fix the issue. I then tried restarting the Finder, and that did fix my issue.
    – jeff-h
    Commented Jul 6, 2019 at 7:23
  • neither restart nor permission changed worked, same issue still exists, ONLY for single mount point (the rest - 9 at last count - all on same server, work without issues). Commented Mar 29, 2021 at 11:49
  • Ditto, restart nor permission change fixed the issue for me, either.
    – John Smith
    Commented Oct 25, 2023 at 18:47

In my case (iMac trying to access files on a Win7 machine) the solution was to add permissions for "Guest" to the Win7 directory. This was previously not necessary. The directory was shareable to everybody and it worked. But apparently now the iMac is trying to connect as "Guest" and adding permissions specifically for "Guest" (Properties…Sharing…Share…Add…Guest) solved it.

  • 4
    This of course bypasses any security you've set up (Guest=public access). So long as you're cool with that, this is a fine solution. Commented Oct 11, 2015 at 14:25

I found I was getting this issue as the finder app was trying to connect as guest by default. I needed to click on the 'connect as' button on the top right.

  • Thanks, this was the issue for me as wel. Once I connected through the "connect as" button and used my credentials, everything worked as expected. It had been a while since I setup the Samba share, so I forgot that I had to use credentials to access the SMB drive...
    – Thijmen
    Commented Feb 10 at 13:34
  • This has been bugging me for a while. This did the trick! Commented May 6 at 18:08

I had the same issue. Also for me it worked on another Mac. It turned out that I had to change the Volumes's group to admin which was wheel befor.

So I fixed my problem with:

sudo chgrp admin /Volumes
  • I had the issue and relaunching Finder did not help. The issue starting occurring after I moved some shares from a Volume to another on a Synology NAS. The fix mentioned above did work for me.
    – Chevdor
    Commented Jan 28, 2018 at 11:39
  • didnt work for me
    – pedjjj
    Commented Nov 17, 2019 at 11:45

TL;DR - Check the permissions on your remote share, too. Make sure the Samba daemon and the AFP daemon have access to the shares.

Long version - My issue was not with my Mac, but with the remote shares. They had 750 permissions, which seemed reasonable since I only wanted the owner and appropriate groups to get access to the folders. But the afpd (Apple File Protocol Daemon) process wasn't in the group! So it was unable to access the files. When other clients, such as my Windows machine accessed the share, they accessed it via Samba (smbd), which was running as root. Thus my Windows machine ran fine, and my Mac client seemed "buggy".

$ ssh myremoteserver
$ ps -eaf | egrep -i smbd\|afpd 
12902 root     34784 S    smbd -D
24642 admin    23680 S    /usr/sbin/afpd -d -F /etc/netatalk/afp.conf

(So Samba's running as root, but AFP is running as "admin".)

$ cd /mnt/myshares
$ ls -l
drwxr-x---    6 nobody   allaccou      4096 Jun 25 02:50 foo
drwxr-x---   11 nobody   allaccou      4096 Jun 10 20:39 bar
drwxr-xr-x   12 nobody   allaccou      4096 Jun 24 23:18 baz

(Here, "baz" works everywhere, but "foo" and "bar" only work on my Windows machine.)

$ sudo cat /etc/group

(So AFP--running as admin--isn't in the group allaccount.)

Add him to the allaccount group and voila, a happy Mac.

  • 2
    I have a Netgear ReadyNAS system and have been having the same issue as OP on all my Mac devices. Your suggestion prompted me to open the admin interface and check out my network shares. Turns out my AFP permissions for each share were too restrictive. So +1 points for you :)
    – Pierce
    Commented Jun 15, 2016 at 9:20

Catalina here. My wife's hard drive and her network share had the same name. This wasn't a problem with Sierra. I changed the hard drive name and boom.

There's a link in /Volumes with the hard drive name linking back to root. I'm guessing Catalina is case insensitive or that link to root didn't exist in Sierra.


Aloha. I had this same issue with a shared volume on OS X Server 5.1 under OS X 10.11.4 beta. Regardless of the fact that these were beta releases, I have had this issue before. Here's how I managed to solve the problem of the "original item" not being found:

  1. log out of the server in Finder
  2. Force-Quit Finder
  3. connect again using Command-K in Finder (or, Go > Connect to Server…)
  4. go back to the shared folder that didn't open before, and it should open fine now

It worked fine for me after that. Note that I do not have the Connect dialog (Command-K in Finder) ever remember my password in the Keychain since I often want to log in as different users. This also helps me troubleshoot once in a while. Also, before doing the above 4 steps, I had gone into the server and removed the shared folder from the File Sharing area and then re-added it, thinking that this would solve the problem; it did not. So therefore, I think the four steps I took (above) were the fix in my situation.

Hope this helps someone.

  • I had a weird situation where the mounted server in the 'Shared' subsection resulted in broken links, but connecting using the 'Connect to server' dialog did end up letting me mount the folders. This happened after server updates, so I'm hoping that the submenu entries will work after all of Finder's caches are flushed at some point, but at least it works for now.
    – Joost
    Commented Apr 16, 2016 at 13:24

I had this problem for an smb share. After checking /etc/smb.conf on the server, I hadn't added the user trying to connect from the client machine to the valid users line for that share. Once I added the user to valid users, the error resolved and I could successfully connect.

  • This was among the top pages when googling this error. This is a very unhelpful error in that it doesn't clearly explain the cause (and it seems there can be many causes--and as the numerous answers attest, many solutions). When I found a resolution to the error that wasn't already posted, I assumed that explaining the solution I found may help future folks who google the error. I also listed the clear, step by step solution I used to resolve the error (edit the specific line of /etc/smb.conf). If this is unhelpful to the community, feel free to remove my answer.
    – roms
    Commented Feb 11, 2020 at 1:59

Had this same issue on a Synology NAS not being able to access specific folders. I realized that I had used one set of credentials on some shared folders, and another set of credentials on other shared folders. Once I figured that out all I had to do was:

  • Locate the NAS in finder
  • In the upper right-corner go to "Disconnect"
  • Then click "Connect As"
  • Enter the other set of credentials

I was then able to access the other folders just fine.


I had the same problem on my MacBook Air; I could not mount shares from a mac OS X Server, when other Macs could.

I had to apply both the chmod and chgrp commands to fix.

I would also recommend restarting into Recovery Mode and running repair disk and repair permissions.


I have a Drobo 5N, and it's network name is "Drobo5N" - I get this error occasionally, and I have noticed that when I get the error, and I look in the Finder, my Drobo is named "drobo5n" (all lower-case). I have not found a way to fix this without rebooting my computer... but, I'd love to find one. (I do not have to do anything to my Drobo - just reboot my Mac.)

After rebooting and running disk repair, my /Volumes ownership and permissions are (OS X 10.10.2):

[~]$ ls -ald /Volumes/
drwxrwxrwt@ 5 root  admin  170 Mar 31 23:41 /Volumes/

and I am currently able to mount my Drobo without any problems.


I just had this issue running on a Macbook Air OS X 10.9.5. The permissions were all fine. I opened the terminal and did

ls -la /Volumes

and got

ls: Photos: Invalid argument

ls: Videos: Invalid argument

These two mounts did NOT show up in Finder. When I tried to unmount them, I get another error:

umount /Volumes/Videos

umount(/Volumes/Videos): Resource busy -- try 'diskutil unmount'

So then I forced an unmount:

diskutil umount force /Volumes/Videos

Unmount successful for /Volumes/Videos

Once I removed all mounts to the network drive (there were 3 of them), I was able to go into Finder -> Go -> Connect to Server and it mounted properly.

I am thinking the IP change may be causing this problem to crop up and for some reason the mounts are tied up and won't unmount. At that point Finder doesn't know how to remount because the old mounts will not unmount properly.

At least that seems to be what my issue was.


In my case, similar to some of the others, it was a permissions problem on the Windows 10 machine that hosted the share I was trying to access. I needed to add permissions to the files (not just the share permissions, but the actual file permissions). Specifically, I needed to either add the "Everyone" group as having access, or (because I didn't really want "everyone" to have access) the specific users I wanted to be able to access the share.

For the specific users, it did work to give access with the Windows Live accounts on a Windows 10 Home machine (in case anyone is thinking, as I initially was, that maybe you need local users and/or a Pro version of Win10).


I experienced this issue shortly after upgrading to macOS Sierra and thought that perhaps permissions or something were messed up in the process. After reading through the other replies here and trying to both force restart Finder, check folder permissions, play with the network share from my router, I finally decided to re-enter the credentials (which were saved in my keychain) for the user I had been logging in as, routinely. This fixed the issue for me.

Takeaway: Try clicking "log in as..." as re-entering credentials for your user, as it worked for me.


After upgrading machines (new one running Sierra) I was setting up my standard favorites and dragging my NAS share (hosted on a Linux box) and always ended up with a "?" in the favorites. After trying everything in this thread, nothing worked.

I found a different solution.

For reference, here's what I've always done (which stopped working as of Sierra):

  1. Click on my network share in the "Shared" section of the finder sidebar
  2. Selected one of the shares in the list
  3. Wait for it to populate in finder (without doing this, the drag operation wouldn't work)
  4. Drag the highlighted share over to the finder sidebar.

Here's what did work (for me):

  1. Go to your network share - just go look at the root directory. This gets it mounted.
  2. In the Devices section of Finder's sidebar, click on your computer (not Macintosh HD.) You should see an entry for each drive connected to your machine, a Network entry, possibly a Remote Disc entry and of course, your share will be listed.
  3. Drag your share from that view into the sidebar.

The solution for me - provided by Synology support - was to convert the shared folder on the Synology NAS to Windows ACL:

Log-in to DSM, Control Panel, Select shared Folder, Action, Convert to Windows ACL


Not truly an answer, but rather an experienced alternative as a temporary workaround ...

After many days of trial-error, research and agonizing, I concluded that my Catalina Mac-mini (as server) with Timemachine External-HD was invisible to my Mojave Macbook. The macbook could see the files on the External-HD from Finder, etc. but Timemachine did not even see the remote External-HD. So, I put my smaller, older WD MyPassport on my macbook as its local Timemachine.

Once I free up enough space to upgrade my macbook to Catalina, I will retry the remote, central server approach to my Timemachine backups.


I would like to share following solution: https://apple.stackexchange.com/a/373068/91135

Turn off packet signing for SMB 2 and SMB 3 connections as described in https://support.apple.com/en-gb/HT205926:

  • Edit /etc/nsmb.conf (create it if necessary)
  • Add
  • Save file Reconnect SMB shares (or reboot your Mac)

In my case it's enough to restart finder process instead of reboot entire system.

This solution helps me with all my network shares, Synology NAS and another Mac in the network.


I'm running Yosemite latest. I ended up renaming the network share on the router, restarting the mac, and, it took a while, but I was then able to access the share under the new name.


Try the following commands in terminal:

  1. First disable airdrop using:

    defaults write com.apple.NetworkBrowser DisableAirDrop -bool YES
  2. Then enable airdrop using:

    defaults write com.apple.NetworkBrowser DisableAirDrop -bool NO
  3. Restart mac


I have had the same problem and found the source of it. When I looked at the console I would see messages from NetAuthSysAgent indicating a sandboxing problem with the sharingd process.

I found that if I kill sharingd, OS X will restart it immediately and I am able to access the NAS shares through finder immediately without anything else needing to be done.

Some time later the problem will return and I have will have to kill sharingd, however this is all I have to do and it's far simpler than many of the other solutions I've seen people writing about.

  • Came here to upvote this answer. After a while I always run into issues connecting to our work synology (DNS name based). My usual fix was force quit finder, but killing the sharingd procces is way quicker and less inconvenient. This problem has been in macOS for years!
    – Lezz
    Commented Mar 22, 2023 at 10:58

In my case, I had set up various permissions according to my needs (users, groups, read only, read/write, etc.) but I also had on permission set to "Everyone":"No Access". I presume that this particular permission overrides any other one. As soon as I changed that one to "Everyone":"Read Only" everything worked like a charm.


None of the existing answers worked in my situation:

  • client: osx/macos 10.x (panther -> catalina)
  • server: debian 6 (squeeze), samba 3.5.6

Turns out the share in question didn't have the correct hosts allow IP range in place to match specific host (i.e. error message is very misleading).


For me nothing worked, So I checked my /Volumes by doing ls /Volumes and got an error.

$ ls -la

ls: Foo: No such file or directory
total 0
drwxr-xr-x   5 root  wheel  160 Jul  7 12:16 .
drwxr-xr-x  23 root  wheel  736 Mar 23 23:19 ..
lrwxr-xr-x   1 root  wheel    1 May  5 19:59 Macintosh HD -> /
drwxr-xr-x@  3 root  wheel   96 Mar 23 23:18 Recovery

So, checked mount and saw that there was an entry:

$ mount

/dev/disk1s1 on / (apfs, local, read-only, journaled)
//username@IP/Foo on /Volumes/Foo (smbfs, nodev, nosuid, mounted by user)

So I unmounted it:

umount /Volumes/Foo

That Fixed the problem.


OS X may have stale mount points; unmount the remote shares so that fresh mount points can take their place. This does not happen automagically.

The GUI way

Try the "eject" icon next to the share in finder, then wait for it to reconnect (or force it with Finder->Go->Connect to Server)

If that doesn't work try the commandline...

The command-line way

Find the existing, probably stale, mounts with mount, then umount them like this...

$ mount
//GUEST:@OPENELEC._smb._tcp.local/videos on /Volumes/videos (smbfs, nodev, nosuid, noowners, mounted by user)
$ umount /Volumes/videos

Now try connecting with Finder again.

In my case I'm trying to connect to a remote Samba share, which has been reconfigured and restarted.


This solves the error message:

"The operation can’t be completed because the original item for BLANK can’t be found"

I was able to fix this by doing the following:

starting my mac in recovery mode by holding cmd + opt + r
selecting disk utility
clicking mount for my SSD
clicking first aid
restart my mac

  • How does manually mounting an internal SSD fix issues with a NAS? Or how you use Disk Utility to mount a NAS using AFP?
    – nohillside
    Commented May 19, 2019 at 13:20
  • its a hardware issue with the internal drive. first aid doesnt erase ur internal drive. it repairs it. the drive isnt mounted when you run ur mac in internet recovery mode so u need to mount it in order to click first aid. Commented May 21, 2019 at 3:39
  • I understand what your answer actually does, I don’t understand how it relates to the question. You mention that you have been able to fix exactly this problem, can you please elaborate what exactly needed fixing here?
    – nohillside
    Commented May 21, 2019 at 4:10
  • the steps i explained get rid of this error message "The operation can’t be completed because the original item for “Foo” can’t be found" Commented May 22, 2019 at 12:51
  • Look, you posted the same answer to several questions covering different problem statements. I don‘t doubt that you used the described steps to get rid of the error message, but did you apply it to a NAS problem as the question asked?
    – nohillside
    Commented May 22, 2019 at 13:44

This is what fixed the issue for me: Make sure the domain "local" is included in the DNS/Search Domains settings for your network connection. That's all I had to do, in my case. See this thread for details: https://discussions.apple.com/thread/8280607

  • This is pretty much a link-only answer. To avoid downvotes you should add the details into your answer instead of linking-out to a different site. Links can change and then your answer will not make sense.
    – fsb
    Commented Sep 26, 2019 at 14:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .