Come si può evitare l'errore43 quando si copia una cartella con collegamenti simbolici in Finder con una condivisione SAMBA?

2

Il contesto

Da un Mac che esegue Mountain Lion, una condivisione "Multimedia" servita da QNAP NAS viene montata come root tramite SAMBA nel Finder. Diciamo che creo un collegamento simbolico di una directory sul NAS come:

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

Funziona:

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

Posso anche mv e cp file senza problemi da e verso symlink quando si accede al NAS.

Questa è la situazione sul lato client, un Mac che esegue 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)

Stranamente, il client non riconosce symlink come tale; è invece una directory normale (si noti che in base all'output ho le autorizzazioni rwx ):

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

Lo stesso accade nel Finder, dove la cartella symlink non appare come un alias, ma come una cartella normale.

Posso cd in symlink e posso anche leggere i file in esso senza problemi. Lo stesso nel Finder.

Il problema

Se provo a scrivere ( mv o cp ) un file in symlink sul lato client, fallisce:

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

Allo stesso modo, qualsiasi tentativo di spostare o copiare un file in symlink tramite il trascinamento della selezione nel Finder restituisce il seguente errore:

The operation cannot be completed because one or more required items cannot be found. (Error code = -43).

(Lo spostamento / copia di un file da symlink in un'altra posizione sul NAS funziona perfettamente.)

Ecco l'output di un'operazione di scrittura nel Terminale:

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

È interessante notare che posso cancellare con successo i file che sono già presenti:

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

Sono davvero in perdita su come diagnosticare e risolvere questo problema.

Il Apple kb rilevante afferma che l'errore -43 può avere tre cause:

  • Caratteri non validi ( nessuno lì )
  • Permessi (le autorizzazioni sembrano buone, vedi l'output ls -la qui sopra. Monta la condivisione con l'account di amministrazione del NAS e sono registrato come amministratore sul mio client Mac . )
  • Punto di condivisione inesistente ( la condivisione esiste e funziona bene altrimenti )

Ulteriori informazioni

Ecco alcune ulteriori informazioni per la risoluzione dei problemi:

Le opzioni globali in /etc/smb.conf sul NAS sono impostate come segue:

[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

Le opzioni specifiche:

[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

I log sul lato del cliente non dicono molto:

/private/var/log/system.log (che include kernel.log dal 10.8) mostra voci occasionali come:

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

E /private/var/log/samba/ non esiste sul mio sistema.

Qualsiasi aiuto è molto apprezzato.

    
posta DBK 14.10.2012 - 20:00
fonte

1 risposta

2

Nella tua configurazione, hai unix extensions = no che va bene, ma è per questo che i link simbolici sul server vengono visualizzati come cartelle e non come alias. In questa modalità il server risolve i collegamenti simbolici e il client non li vede mai. Se il client tenta di creare un collegamento simbolico, il server genera effettivamente un file alias, non un collegamento simbolico del SO host. Le ragioni di ciò includono la sicurezza (impedendo a qualcuno di ottenere l'accesso a /etc/passwd sul server creando un collegamento simbolico ad esso) e la compatibilità con il client, dato che OS X e Windows e Unix hanno idee leggermente diverse su ciò che costituisce un collegamento simbolico molto d'accordo su cosa sia una directory o un file.

I problemi relativi alle autorizzazioni con SAMBA sono complessi, quindi non è chiaro se non si dispone di un problema di autorizzazioni. Allo stesso modo la risoluzione simbolica è complessa, quindi non è chiaro che ciò che si sta facendo dovrebbe, in teoria, funzionare e c'è sempre la possibilità di un bug (molto probabilmente nel server SAMBA).

Quando si accede a un server SAMBA da un Mac, queste identità e permessi sono coinvolti:

  • Utente Mac che hai effettuato l'accesso al Mac come
  • L'utente SAMBA è collegato al server SAMBA come
  • L'utente del sistema operativo host del server SMABA viene convertito in
  • Permessi di file in stile Unix
  • Per NTFS e HFS +, ACL del file system associati

Quindi, anche se hai fornito molte informazioni, non è ancora chiaro se non stai riscontrando problemi di autorizzazione. Il fatto che tu possa mv e cp sul server (usando quale account?) Non significa che non hai un problema di permessi che ti impedisce di farlo sul client (usando quali account e con quale account efficace sul server?).

Se il server supporta ACL e poiché sono presenti opzioni come inherit permissions = yes e inherit acls = yes , potrebbe esserci qualche tipo di problema ACL che consente solo l'accesso in lettura alle directory accessibili tramite collegamenti simbolici. Esistono diverse altre modalità di indagine basate sulla configurazione del server.

Mi aspetto che tu possa trovare più informazioni nei log del server SAMBA di quante ne hai comunicate. Dovrebbero darti un senso molto migliore di ciò che viene negato.

Per quel che vale, ho provato a duplicare la configurazione utilizzando un host Ubuntu 12.04 come server SAMBA e non è stato possibile riprodurre il problema. I collegamenti simbolici hanno funzionato per me come previsto.

    
risposta data 23.10.2012 - 23:16
fonte

Leggi altre domande sui tag