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

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?

Solution 1:

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.

Solution 2:

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.

Solution 3:

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.

Solution 4:

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

Solution 5:

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
root:x:0:root
administrators:x:1001:admin
share:!:1000:admin,nobody
allaccount:!:501:bob,jane,sue
netdev:x:1002:

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

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