Le contexte

À partir d'un Mac exécutant Mountain Lion, un partage "Multimédia" servi par QNAP NAS est monté en tant que racine via SAMBA dans le Finder. Supposons que je crée un lien symbolique d'un répertoire sur le NAS, tel que:

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

Ça marche:

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

Je peux aussi mvet cpfichiers sans problèmes à et à partir symlinklorsque connecté sur le NAS.

Voici la situation côté client, un Mac sous 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)

Étrangement, le client ne reconnaît pas en symlinktant que tel; c'est un répertoire normal à la place (veuillez noter que selon le résultat, j'ai des rwxpermissions):

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

La même chose se produit dans le Finder, où le dossier symlinkn'apparaît pas comme un alias, mais comme un dossier normal.

Je peux cden symlinket je peux aussi lire les fichiers sans problèmes. La même chose dans le Finder.

Le problème

Si j'essaie d'écrire ( mvou cp) un fichier symlinkcôté client, cela échoue:

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

De même, toute tentative de déplacement ou de copie d'un fichier symlinkvia glisser-déposer dans le Finder renvoie l'erreur suivante:

L'opération ne peut pas être terminée car un ou plusieurs éléments requis sont introuvables. (Code d'erreur = -43).

(Déplacer / copier un fichier d' symlink un autre emplacement sur le NAS fonctionne très bien.)

Voici le résultat d'une opération d'écriture dans le terminal:

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

Fait intéressant, je peux supprimer avec succès les fichiers déjà présents:

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

Je ne sais vraiment pas comment diagnostiquer et résoudre ce problème.

Le kb Apple correspondant indique que l'erreur -43 peut avoir trois causes:

• Personnages illégaux ( aucun là-bas )
• Autorisations (les autorisations semblent bonnes, voir le ls -la résultat ci-dessus. Je monte le partage avec le compte administrateur du NAS et je suis connecté en tant qu'administrateur sur mon client Mac. )
• Point de partage inexistant ( le partage existe et fonctionne bien sinon )

Informations supplémentaires

Voici quelques informations supplémentaires pour le dépannage:

Les options globales /etc/smb.confdu NAS sont définies comme suit:

[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

Les options spécifiques:

[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

Les journaux du côté du client ne disent pas grand chose:

/private/var/log/system.log (qui inclut kernel.log depuis 10.8) affiche des entrées occasionnelles telles que:

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

Et /private/var/log/samba/n'existe pas sur mon système.

Toute aide est très appréciée.

Dans votre configuration, vous avez unix extensions = noce qui convient, mais c’est la raison pour laquelle les liens symboliques sur le serveur apparaissent sous forme de dossiers et non d’alias. Dans ce mode, le serveur résout les liens symboliques et le client ne les voit jamais. Si le client tente de créer un lien symbolique, le serveur génère en fait un fichier alias, pas un lien symbolique hôte-système d'exploitation. Les raisons en sont notamment la sécurité (empêcher toute personne d’avoir accès au /etc/passwdserveur en créant un lien symbolique avec celui-ci) et la compatibilité client, car OS X, Windows et Unix ont des idées légèrement différentes sur ce qui constitue un lien symbolique, mais ils s’accordent à peu près. Qu'est-ce qu'un répertoire ou un fichier?

Les problèmes d'autorisations avec SAMBA sont complexes, il n'est donc pas clair que vous n'ayez pas de problème d'autorisations. De même, la résolution symbolique est complexe, il n'est donc pas clair que ce que vous faites doit fonctionner en théorie, et il existe toujours la possibilité d'un bogue (très probablement sur le serveur SAMBA).

Lors de l'accès à un serveur SAMBA à partir d'un Mac, ces identités et autorisations sont impliquées:

• L'utilisateur Mac sur lequel vous êtes connecté au Mac en tant que
• L'utilisateur SAMBA vous êtes connecté au serveur SAMBA en tant que
• L'utilisateur du système d'exploitation hôte du serveur SMABA pour lequel vous êtes converti
• Permissions de fichiers de style Unix
• Pour NTFS et HFS +, ACL associées au système de fichiers

Ainsi, même si vous avez fourni beaucoup d'informations, il n'est toujours pas clair que vous ne rencontrez pas de problèmes d'autorisations. Le fait que vous puissiez mvet cpsur le serveur (avec quel compte?) Ne signifie pas que vous n’avez pas de problème d’autorisations vous empêchant de le faire sur le client (avec quels comptes et avec quel compte effectif sur le serveur?).

Si le serveur prend en charge les listes de contrôle d'accès et que vous disposez d'options telles que inherit permissions = yeset inherit acls = yesdéfinies, il pourrait en résulter un problème quelconque lié aux listes de contrôle d'accès qui autorise uniquement l'accès en lecture aux répertoires accessibles via des liens symboliques. Il existe plusieurs autres domaines d’investigation basés sur la configuration du serveur.

Je m'attendrais vraiment à ce que vous puissiez trouver plus d'informations dans les journaux du serveur SAMBA que vous n'en avez communiquées. Ils devraient vous donner une bien meilleure idée de ce qui est refusé.

Pour ce que cela vaut, j'ai essayé de dupliquer votre configuration en utilisant un hôte Ubuntu 12.04 comme serveur SAMBA et ne pouvais pas reproduire votre problème. Les liens symboliques ont fonctionné pour moi comme prévu.