¿Cómo puede evitar el error -43 al copiar una carpeta de enlace simbólico en el Finder con un recurso compartido de SAMBA?

2

El contexto

Desde una Mac que ejecuta Mountain Lion, un recurso "Multimedia" compartido por QNAP NAS se monta como root a través de SAMBA en el Finder. Digamos que creo un enlace simbólico de un directorio en el NAS como:

[/share/Multimedia] # ln -s /share/MD0_DATA/Multimedia/test/ ./folder/symlink     

Funciona:

[/share/Multimedia] # ls -la folder
lrwxrwxrwx  1 admin  administ  34 Oct 14 19:24 symlink -> /share/MD0_DATA/Multimedia/test//

También puedo ingresar los archivos mv y cp sin problemas desde y hacia symlink cuando se registra en el NAS.

Esta es la situación en el lado del cliente, una Mac que ejecuta 10.8.2:

client:~ myself$ id
uid=501(myself) gid=20(staff) groups=20(staff),401(com.apple.access_screensharing),
12(everyone),33(_appstore),61(localaccounts),79(_appserverusr),80(admin),
81(_appserveradm),98(_lpadmin),100(_lpoperator),204(_developer)

Extrañamente, el cliente no reconoce symlink como tal; es un directorio normal en su lugar (tenga en cuenta que de acuerdo con la salida tengo rwx permisos):

client:folder myself$ ls -la
drwx------  1 myself  staff  16384 18 Okt 23:25 symlink

Lo mismo ocurre en el Finder, donde la carpeta symlink no aparece como un alias, sino como una carpeta normal.

Puedo cd en symlink y también puedo leer archivos sin problemas. Lo mismo en el Finder.

El problema

Si intento escribir ( mv o cp ) un archivo en symlink en el lado del cliente, falla:

 client:folder myself$ mv test.txt symlink/
 mv: rename test.txt to symlink/test.txt: No such file or directory

Del mismo modo, cualquier intento de mover o copiar un archivo en symlink mediante arrastrar y soltar en el Finder devuelve el siguiente error:

  

La operación no se puede completar porque no se pueden encontrar uno o más elementos necesarios. (Código de error = -43).

(Mover / copiar un archivo de symlink a otra ubicación en el NAS funciona bien).

Aquí está la salida de una operación de escritura en la Terminal:

 client:symlink myself$ touch text.txt
 touch: text.txt: Permission denied

Curiosamente, puedo eliminar con éxito los archivos que ya están presentes:

 client:symlink myself$ ls -la
 total 64
 drwx------  1 myself  staff  16384 18 Okt 23:51 .
 drwx------  1 myself  staff  16384 18 Okt 23:48 ..
 -rwx------  1 myself  staff      5 18 Okt 23:51 text.txt
 client:symlink myself$ rm text.txt 
 client:symlink myself$ ls -la
 total 64
 drwx------  1 myself  staff  16384 18 Okt 23:56 .
 drwx------  1 myself  staff  16384 18 Okt 23:48 ..

Realmente no entiendo cómo diagnosticar y resolver este problema.

El Apple kb relevante indica que el Error -43 puede tener tres causas:

  • Caracteres ilegales ( ninguno allí )
  • Permisos (los permisos parecen estar bien, consulte la salida ls -la anterior. Monté el recurso compartido con la cuenta de administrador del NAS y estoy registrado como administrador en mi cliente Mac) . )
  • Punto compartido inexistente ( el recurso compartido existe y funciona bien de otra manera )

Información adicional

Aquí hay más información para solucionar problemas:

Las opciones globales en /etc/smb.conf en el NAS se establecen de la siguiente manera:

[global]
passdb backend = smbpasswd
workgroup = WORKGROUP
security = USER
server string =
encrypt passwords = Yes
username level = 0
map to guest = Bad User
null passwords = yes
max log size = 10
socket options = TCP_NODELAY SO_KEEPALIVE SO_SNDBUF=65536 SO_RCVBUF=65536
os level = 20
preferred master = no
dns proxy = No
smb passwd file=/etc/config/smbpasswd   
username map = /etc/config/smbusers
guest account = guest
directory mask = 0777
create mask = 0777
oplocks = yes
locking = yes
disable spoolss = yes
load printers = no
force directory security mode = 0000
veto files = /.AppleDB/.AppleDouble/.AppleDesktop/:2eDS_Store/Network Trash Folder/Temporary Items/TheVolumeSettingsFolder/.@__thumb/.@__desc/:2e*/
delete veto files = yes
map archive = no
map system = no
map hidden = no
map read only = no
deadtime = 10
use sendfile = yes
display charset = UTF8
unix extensions = no
store dos attributes = yes
client ntlmv2 auth = yes
dos filetime resolution = no
min receivefile size = 4096
case sensitive = auto
domain master = auto
local master = yes
inherit acls = yes
wide links = yes
follow symlinks = yes
wins support = no
force unknown acl user = yes
template homedir = /share/homes/DOMAIN=%D/%U
domain logons = no

Las opciones específicas:

[Multimedia]
comment = System default share
path = /share/MD0_DATA/Multimedia
browsable = yes
oplocks = no
ftp write only = no
public = yes
invalid users =
read list = @"everyone","gast"
write list = "admin","guest"
valid users = "root",@"everyone","admin","guest","gast"
inherit permissions = yes

Los registros en el lado del cliente no dicen mucho:

/private/var/log/system.log (que incluye kernel.log desde 10.8) muestra entradas ocasionales como:

 Oct 18 22:13:43 client kernel[0]: smb_iod_reconnect: Reconnected share MULTIMEDIA with server qnap-SAMBA._smb._tcp.local

Y /private/var/log/samba/ no existe en mi sistema.

Cualquier ayuda es muy apreciada.

    
pregunta DBK 14.10.2012 - 20:00

1 respuesta

2

En su configuración, tiene unix extensions = no , lo cual está bien, pero es por eso que los enlaces simbólicos en el servidor se muestran como carpetas y no como alias. En este modo, el servidor resuelve los enlaces simbólicos y el cliente nunca los ve. Si el cliente intenta crear un enlace simbólico, el servidor realmente genera un archivo de alias, no un enlace simbólico del sistema operativo. Las razones para esto incluyen la seguridad (que impide que alguien tenga acceso a /etc/passwd en el servidor mediante la creación de un enlace simbólico) y la compatibilidad del cliente, ya que OS X, Windows y Unix tienen ideas ligeramente diferentes acerca de lo que constituye un enlace simbólico, pero son bastante importantes. Estoy de acuerdo en qué es un directorio o un archivo.

Los problemas de permisos con SAMBA son complejos, por lo que no está claro que no tenga un problema de permisos. Del mismo modo, simbólico como la resolución es complejo, por lo que no está claro que lo que estás haciendo debería, en teoría, funcionar, y siempre existe la posibilidad de un error (muy probablemente en el servidor SAMBA).

Al acceder a un servidor SAMBA desde una Mac, se incluyen estas identidades y permisos:

  • El usuario de Mac con el que has iniciado sesión en la Mac como
  • El usuario SAMBA con el que ha iniciado sesión en el servidor SAMBA como
  • El usuario del sistema operativo host del servidor SMABA al que te conviertes
  • Permisos de archivos de estilo Unix
  • Para NTFS y HFS +, las ACL asociadas del sistema de archivos

Entonces, a pesar de que ha proporcionado mucha información, todavía no está claro que no tenga problemas con los permisos. El hecho de que pueda mv y cp en el servidor (¿usando qué cuenta?) No significa que no tenga un problema de permisos que le impida hacerlo en el cliente (usando qué cuentas y con qué cuenta efectiva en el servidor). servidor?).

Si el servidor admite ACL y, dado que tiene opciones como inherit permissions = yes y inherit acls = yes establecido, puede haber algún tipo de problema de ACL que solo permita el acceso de lectura a los directorios a los que se accede mediante enlaces simbólicos. Hay varias otras vías de investigación basadas en la configuración del servidor.

Realmente espero que pueda encontrar más información en los registros del servidor SAMBA de la que se ha comunicado. Deben darle una mejor idea de lo que se está negando.

Para lo que vale, intenté duplicar su configuración utilizando un host Ubuntu 12.04 como servidor SAMBA y no pude reproducir su problema. Los enlaces simbólicos funcionaron para mí como se esperaba.

    
respondido por el Old Pro 23.10.2012 - 23:16

Lea otras preguntas en las etiquetas