87

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?

| improve this question | | | | |

23 Answers 23

105

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.
| improve this answer | | | | |
  • 38
    Relaunching the finder worked for me too. Apple menu (top left) -> Force Quit -> Finder -> Relaunch. – cgenco May 19 '16 at 21:13
  • 1
    WFM too: OSX El Capitan, Force quit finder and now able to re-connect to a late 2008 macbook. Thanks – jalanb Jun 6 '16 at 17:22
  • 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 Jan 7 '17 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 Apr 19 '17 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 Oct 2 '17 at 17:57
8

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.

| improve this answer | | | | |
  • 3
    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. – inanutshellus Oct 11 '15 at 14:25
6

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.

| improve this answer | | | | |
  • 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 Jul 6 '19 at 7:23
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
| improve this answer | | | | |
  • 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 Jan 28 '18 at 11:39
  • didnt work for me – pedjjj Nov 17 '19 at 11:45
3

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.

| improve this answer | | | | |
  • 1
    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 Jun 15 '16 at 9:20
2

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.

| improve this answer | | | | |
  • 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 Apr 16 '16 at 13:24
1

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.

| improve this answer | | | | |
1

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.

| improve this answer | | | | |
1

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.

| improve this answer | | | | |
1

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.
| improve this answer | | | | |
1

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.

| improve this answer | | | | |
  • 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 Feb 11 at 1:59
1

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.

| improve this answer | | | | |
0

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.

| improve this answer | | | | |
0

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.

| improve this answer | | | | |
0

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

| improve this answer | | | | |
0

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.

| improve this answer | | | | |
0

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

| improve this answer | | | | |
0

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.

| improve this answer | | | | |
0

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.

| improve this answer | | | | |
0

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

| improve this answer | | | | |
0

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.

| improve this answer | | | | |
-1

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

| improve this answer | | | | |
  • 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 May 19 '19 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. – incognito nerd May 21 '19 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 May 21 '19 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" – incognito nerd May 22 '19 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 May 22 '19 at 13:44
-1

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

| improve this answer | | | | |
  • 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 Sep 26 '19 at 14:20

You must log in to answer this question.

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