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 -laré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.
drwxrwxrwx 2 admin administ 4096 Oct 19 21:12 test/.
ln -s /share/MD0_DATA/Multimedia/test/ etc.la syntaxe semble être incorrecte (notez la barre oblique à la fin). Cependant, ln -s /share/MD0_DATA/Multimedia/test etc.cela ne change pas la situation.
cd /share/MD0_DATA/Multimedia/folder; ln -s ../test ./symlink. Probablement pas aide, mais pas une autre idée et peut - être une exportation quelque peu chambouler les chemins absolus par la vue du client ...
mvet cpfichiers sans problèmes de et vers symlink" et "Si j'essaie d'écrire ( mvou cp) un fichier dans symlink, il échoue", alors je suis confus.
ls -ld /share/MD0_DATA/Multimedia/test/résultat de la commande. Alors, quelle est la permission du répertoire où le lien symbolique pointe.