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

apple.stackexchange https://apple.stackexchange.com/questions/353673

  •  29-04-2021
  •  | 
  •  

Question

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?

Was it helpful?

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.

OTHER TIPS

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.

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.

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

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.

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 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 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.

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.

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.

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).

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.

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.

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 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.

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

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
[default]
signing_required=no
  • 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.

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.

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

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

Licensed under: CC-BY-SA with attribution
Not affiliated with apple.stackexchange
scroll top