2 votos

¿Cómo se puede evitar errores -43 al copiar un enlace simbólico carpeta en el Finder con una cuota de SAMBA?

El contexto

Desde un Mac con Mountain Lion, un compartir "Multimedia" servido por QNAP NAS es montado como root a través de SAMBA en el Finder. Digamos que crear un enlace simbólico de un directorio en el NAS, tales 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 mv y cp archivos sin problemas y desde symlink cuando inicie sesión en el NAS.

Esta es la situación en el lado del cliente, en un Mac con 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 reconozca symlink como tal; es un directorio normal en lugar de (por favor, tenga en cuenta que de acuerdo a la salida he rwx permisos):

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

Lo mismo sucede en el Buscador, donde la carpeta symlink no aparece como un alias, pero como una carpeta normal.

Puedo cd a symlink y también puede leer archivos en ella sin problemas. El mismo en el Buscador.

El problema

Si trato de escribir (mv o cp) un archivo en symlink en el lado del cliente, se produce un error:

 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 a través de arrastrar-n-gota en el Buscador devuelve el siguiente error:

La operación no se puede completar debido a que uno o más elementos que no se pueden encontrar. (Código de Error = -43).

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

He aquí el resultado de una operación de escritura en el Terminal:

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

Curiosamente, puedo eliminar correctamente 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 ..

Estoy realmente en la pérdida sobre cómo diagnosticar y solucionar este problema.

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

  • Caracteres ilegales (ninguno no)
  • Permisos (permisos parecen estar bien, ver el ls -la resultado anterior. Yo monte el compartir con la cuenta de administrador de la NAS y estoy conectado como administrador en mi Mac del cliente.)
  • No existe punto de recurso compartido (la proporción que existe y funciona bien lo contrario)

Información adicional

He aquí algo más de información para la solución de problemas:

Las opciones globales en /etc/smb.conf en el NAS se establecen como sigue:

[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 el kernel.registro desde 10.8) se muestra ocasional de entradas 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.

2voto

Old Pro Puntos 2851

En su configuración, usted tiene unix extensions = no lo cual está bien, pero que es la razón por la que los enlaces simbólicos en el servidor que aparecen como carpetas y no de alias. En este modo, el servidor resuelve los enlaces simbólicos y el cliente nunca ve. Si el cliente intenta crear un enlace simbólico, el servidor genera un archivo de alias, no un host OS vínculo simbólico. Las razones para esto incluyen la seguridad (prevención de alguien de acceso a /etc/passwd en el servidor mediante la creación de un vínculo simbólico) y de compatibilidad del cliente, como OS X y Windows y Unix ligeramente diferentes ideas sobre lo que constituye un enlace simbólico pero se bastante de acuerdo en qué es un directorio o un archivo.

Problemas de permisos con SAMBA son complejos, por lo que no está claro que usted no tiene un problema de permisos. Del mismo modo simbólico como la resolución es compleja, por lo que no está claro que lo que está haciendo debería, en teoría, el trabajo, y siempre existe la posibilidad de un error (lo más probable en el servidor SAMBA).

Cuando se accede a un servidor SAMBA desde un Mac, estas identidades y los permisos están involucrados:

  • El Usuario de Mac está conectado a la Mac como
  • La SAMBA del usuario que haya iniciado sesión en el servidor SAMBA como
  • El SMABA de host del servidor de usuario del sistema operativo que se convierten en
  • De estilo Unix permisos de archivo
  • Para NTFS y HFS+, archivo asociado-sistema de Acl

Así que a pesar de que usted ha proporcionado una gran cantidad de información, aún no está claro que usted no está teniendo problemas de permisos. El hecho de que usted puede mv y cp en el servidor (usando lo que se cuenta?) no significa que usted no tiene un problema de permisos que le impide hacerlo en el cliente (usando lo que cuentas y con lo que efectivos de la cuenta en el servidor?).

Si el servidor que soporte Acl y ya que usted tiene opciones como inherit permissions = yes y inherit acls = yes conjunto podría haber algún tipo de ACL problema que sólo se permite el acceso de lectura a los directorios acceder a través de enlaces simbólicos. Hay varias otras vías de investigación basado en la configuración del servidor.

Realmente esperamos que usted debería ser capaz de encontrar más información en el servidor SAMBA registros de que se haya comunicado. Le deberían dar una mejor idea de lo que está siendo negada.

Para lo que vale, he tratado de duplicar su instalación utilizando un Ubuntu 12.04 host que el servidor SAMBA y que no podía reproducir el problema. Los enlaces simbólicos para mí funcionaba como se esperaba.

AppleAyuda.com

AppleAyuda es una comunidad de usuarios de los productos de Apple en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X