La operación no se puede completar porque no se puede encontrar el elemento original de "Foo"

Ok, así que voy a responder mi propia pregunta. En mi caso, la solución resultó ser realmente 'simple'.

Miré a otra Mac y noté que el directorio /Volumes tenía permisos diferentes. En la Mac problemática, se estableció en drwxr-xr-x y en una Mac recientemente instalada, fue drwxrwxr-x .

Así que solucioné mi problema con:

sudo chmod 775 /Volumes

(También puede hacerlo en el Finder, por supuesto, a través de Obtener información)

Problema resuelto. Ahora puedo montar cualquier archivo compartido de nuevo.

Al parecer, este problema puede ocurrir por muchas razones diferentes. En mi caso se resolvió relanzando el buscador. Una descripción y solución para esto fue en enlace .

En mi caso (iMac que intenta acceder a los archivos en una máquina Win7), la solución fue agregar permisos para "Invitado" al directorio de Win7. Esto anteriormente no era necesario. El directorio fue compartido por todos y funcionó. Pero aparentemente ahora el iMac está intentando conectarse como "Invitado" y agregar permisos específicamente para "Invitado" (Propiedades ... Compartir ... Compartir ... Agregar ... Invitado) lo resolvió.

Tuve el mismo problema. También para mí funcionó en otra Mac. Resultó que tenía que cambiar el grupo de Volumes a admin , que era wheel antes.

Así que solucioné mi problema con:

sudo chgrp admin /Volumes

TL; DR : compruebe también los permisos en su recurso compartido remoto. Asegúrese de que el daemon de Samba y el daemon de AFP tenga acceso a los recursos compartidos.

Versión larga : mi problema no era con mi Mac, sino con los recursos compartidos remotos. Tenían 750 permisos, que parecían razonables ya que solo quería que el propietario y los grupos apropiados tuvieran acceso a las carpetas. ¡Pero el proceso afpd (Apple File Protocol Daemon) no estaba en el grupo! Así que no pudo acceder a los archivos. Cuando otros clientes, como mi máquina con Windows accedieron al recurso compartido, accedieron a él a través de Samba ( smbd ), que se ejecutaba como root . Por lo tanto, mi máquina con Windows funcionó bien y mi cliente Mac parecía tener "bugs".

$ 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

(Así que Samba se ejecuta como root, pero AFP se ejecuta como "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

(Aquí, "baz" funciona en todas partes, pero "foo" y "bar" solo funcionan en mi máquina con Windows.)

$ sudo cat /etc/group
root:x:0:root
administrators:x:1001:admin
share:!:1000:admin,nobody
allaccount:!:501:bob,jane,sue
netdev:x:1002:

(Por lo tanto, AFP, que se ejecuta como admin , no está en el grupo allaccount .)

Añádalo a allaccount group y voila , una Mac feliz.

Tuve el mismo problema en mi MacBook Air; No podía montar recursos compartidos desde un Mac OS X Server, cuando otros Mac sí podían.

Tuve que aplicar los comandos chmod y chgrp para corregir.

También recomendaría reiniciar en modo de recuperación y ejecutar el disco de reparación y los permisos de reparación.

Tengo un Drobo 5N, y su nombre de red es "Drobo5N". Recibo este error ocasionalmente, y he notado que cuando recibo el error y busco en el Finder, mi Drobo se llama "drobo5n" ( todo en minúsculas). No he encontrado una manera de solucionar este problema sin reiniciar mi computadora ... pero me encantaría encontrar una. (No tengo que hacer nada con mi Drobo, solo reinicie mi Mac).

Después de reiniciar y ejecutar la reparación del disco, la propiedad y los permisos de my / Volumes son (OS X 10.10.2):

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

y actualmente puedo montar mi Drobo sin ningún problema.

Aloha. Tuve este mismo problema con un volumen compartido en OS X Server 5.1 bajo OS X 10.11.4 beta. Independientemente del hecho de que se trata de versiones beta, he tenido este problema antes. Así es como logré resolver el problema del "elemento original" que no se encuentra:

1. cierre la sesión del servidor en el Finder
2. Force-Quit Finder
3. vuelva a conectarse usando Command-K en el Finder (o, Ir > Conectar al servidor ...)
4. vuelva a la carpeta compartida que no se abrió antes, y debería estar bien ahora

Me funcionó bien después de eso. Tenga en cuenta que no tengo el cuadro de diálogo Conectar (Comando-K en Finder) alguna vez que recuerde mi contraseña en el llavero, ya que a menudo quiero iniciar sesión como usuarios diferentes. Esto también me ayuda a solucionar problemas de vez en cuando. Además, antes de realizar los 4 pasos anteriores, entré en el servidor y eliminé la carpeta compartida del área de uso compartido de archivos y luego la volví a agregar, pensando que esto resolvería el problema; no lo hizo. Por lo tanto, creo que los cuatro pasos que tomé (arriba) fueron la solución a mi situación.

Espero que esto ayude a alguien.

Después de actualizar las máquinas (una nueva con Sierra) estaba configurando mis favoritos estándar y arrastrando mi recurso compartido NAS (alojado en una caja de Linux) y siempre terminaba con un "?" en los favoritos. Después de intentar todo en este hilo, nada funcionó.

Encontré una solución diferente.

Para referencia, esto es lo que siempre he hecho (que dejó de funcionar a partir de Sierra):

1. Haga clic en mi recurso compartido de red en la sección "Compartido" de la barra lateral del buscador
2. Seleccionó una de las acciones en la lista
3. Espere a que se complete en el buscador (sin hacer esto, la operación de arrastre no funcionaría)
4. Arrastre el recurso compartido resaltado a la barra lateral del buscador.

Esto es lo que funcionó (para mí):

1. Vaya a su recurso compartido de red: solo vea el directorio raíz. Esto lo consigue montado.
2. En la sección Dispositivos de la barra lateral del Finder, haga clic en su computadora (no en Macintosh HD). Debería ver una entrada para cada unidad conectada a su máquina, una entrada de Red, posiblemente una entrada de Disco Remoto y, por supuesto, su recurso compartido estar en la lista.
3. Arrastra tu parte desde esa vista a la barra lateral.

Acabo de tener este problema ejecutándose en un Macbook Air OS X 10.9.5. Los permisos estaban todos bien. Abrí la terminal y lo hice

  

ls -la / Volumes

y obtuve

  

ls: Fotos: argumento no válido

     

ls: Videos: Argumento no válido

Estos dos montajes NO se mostraron en el Finder. Cuando intenté desmontarlos, me sale otro error:

  

umount / Volumes / Videos

     

umount (/ Volumes / Videos): Recurso ocupado: intente 'diskutil unmount'

Entonces forzé un desmontaje:

  

diskutil umount force / Volumes / Videos

     

Desmontaje exitoso para / Volúmenes / Videos

Una vez que quité todos los montajes a la unidad de red (había 3 de ellos), pude ir al Finder - > Ir - > Conéctese al servidor y se montó correctamente.

Estoy pensando que el cambio de IP puede estar causando que este problema surja y, por alguna razón, los montajes están atados y no se desmontan. En ese momento, el Finder no sabe cómo volver a montar porque las monturas antiguas no se desmontarán correctamente.

Al menos eso parece ser mi problema.

17 JUN 2015 Estoy corriendo Yosemite más reciente. Después de horas de buscar y probar todo, terminé cambiando el nombre del recurso compartido de red en el enrutador, reiniciando el mac y, tomó un tiempo, pero luego pude acceder al recurso compartido con el nuevo nombre.

OS X puede tener puntos de montaje obsoletos; desmonte los recursos compartidos remotos para que los nuevos puntos de montaje puedan ocupar su lugar. Esto no sucede automáticamente.

El modo GUI

Pruebe el ícono "expulsar" junto al recurso compartido en el buscador, luego espere a que se vuelva a conectar (o fuerce con Finder- > Go- > Connect to Server)

Si eso no funciona, prueba la línea de comandos ...

La forma de línea de comandos

Encuentra los montajes existentes, probablemente obsoletos, con mount , luego umount ellos de esta manera ...

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

Ahora intenta conectarte de nuevo con el Finder.

En mi caso, estoy tratando de conectarme a un recurso compartido remoto de Samba, que se ha reconfigurado y reiniciado.

En mi caso, similar a algunos de los demás, fue un problema de permisos en la máquina con Windows 10 que alojó el recurso compartido al que intentaba acceder. Necesitaba agregar permisos a los archivos (no solo los permisos de compartir, sino los permisos de archivos reales). Específicamente, necesitaba agregar el grupo "Todos" como tener acceso, o (porque realmente no quería que "todos" tuvieran acceso) a los usuarios específicos a los que quería poder acceder al recurso compartido.

Para los usuarios específicos, funcionó para dar acceso a las cuentas de Windows Live en una máquina Windows 10 Home (en caso de que alguien esté pensando, como inicialmente pensé, que tal vez necesite usuarios locales y / o una versión Pro de Win10).

Experimenté este problema poco después de actualizar a macOS Sierra y pensé que tal vez los permisos o algo se habían desordenado en el proceso. Después de leer las otras respuestas aquí e intentar forzar el reinicio del Finder, verificar los permisos de la carpeta, jugar con el recurso compartido de red desde mi enrutador, finalmente decidí volver a ingresar las credenciales (que estaban guardadas en mi llavero) para el usuario que tenía estado iniciando sesión como, rutinariamente. Esto solucionó el problema para mí.

Para llevar: intenta hacer clic en "iniciar sesión como ..." para volver a ingresar las credenciales de tu usuario, ya que me funcionó.

Encontré que estaba teniendo este problema porque la aplicación del buscador estaba intentando conectarse como invitado de forma predeterminada. Necesitaba hacer clic en el botón "conectar como" en la parte superior derecha.