Faq numero:

58

Curata da:

Marco Balestra

Argomenti:

Errori e conflitti,  Reti (LAN) Mac e miste,  Sicurezza dei dati e privacy

La Faq in XML+XSLT:

http://faqintosh.com/faq/58.xml - XML della Faq: http://faqintosh.com/faq/58-data.xml

Dall’ultima revisione:

4804 giorni, 4 ore, 52 minuti

Faq correlate:

Faq 221 - Come attivare la condivisione in una rete tra Mac OS X e Windows 2000 o XP?
Faq 322 - Perché nel Finder di Tiger (10.4.x) il pulsante "Connessione..." sotto una risorsa di rete non funziona?
Faq 136 - Come mettere in rete un Mac ed un PC via ethernet?
Faq 238 - Perché con Panther lo scambio di file in rete locale va così lentamente?
Faq 5 - Posso aprire velocemente elementi in TextEdit con privilegi root?

Mac OS X 10.4 (Tiger)

• Fonte: support.apple.com/kb/TS1564

Accedendo da Mac OS X 10.4 Tiger (ovvero da Mac OS X 10.3 Panther aggiornato a Mac OS X 10.4 Tiger) ad uno share Samba o Windows (SMB/CIFS) è possibile incontrare questo errore:

The Finder cannot complete the operation because some of the data in smb://… could not be read or written. (Error code -36).

Ovvero:

Impossibile completare l’operazione. Alcuni dati in smb://… non possono essere letti o scritti. (Errore -36).

Questo accade perché il server (Windows o comunque SMB/CIFS) supporta solo autenticazione con password in chiaro, mentre OS X dalla versione 10.4 richiede che le password siano almeno crittate, e non manda quindi la password in chiaro.

Il primo e più logico passaggio ovviamente è quello di contattare l’amminsitratore di dominio/rete/server e chiedergli di supportare (o supportare anche) le autenticazioni con password crittate.
Qualora questo non fosse possibile dovremo dire ad OS X di piegarsi e di inviare la password “in chiaro”.

Per farlo occorre modificare il file /etc/nsmb.conf con privilegi di root. Con un utente amministratore della macchina:

1. Aprire il Terminale (/Applications/Utilities/Terminal.app)
2. Digitare: sudo touch /etc/nsmb.conf e dare Invio; digitare la propria password quando richiesto.
3. Digitare: sudo chmod a+rw /etc/nsmb.conf e dare Invio; digitare la propria password se richiesto.
4. Digitare: open -a /Applications/TextEdit.app/Contents/MacOS/TextEdit /etc/nsmb.conf e dare Invio.
5. Il file dovrà essere modificato per contenere:

   [default]
   minauth=none

6. Salvare il file (solo testo, se lo chiede) e chiuderlo
7. Digitare nel Terminale: sudo chmod a+r,a-w /etc/nsmb.conf e dare Invio; digitare la propria password se richiesto.

Al termine delle operazioni riavviare il Mac, che ora supporterà le password in “cleartext”.

Mac OS X fino a 10.3 (Panther e precedenti)

• Fonte: www.macosxhints.com ed allinthehead.com

Scenario: server windows 2003 Primary Domain Controller e file server, con il Macintosh File Server installato.

Cercando di accedere da Mac OS X verso uno share di Windows 2003 si ottiene un errore:

• «errore -5000» se si tenta un accesso samba ("smb://...")
• «errore -35» in caso di accesso ad uno share Mac ("afp://...")

La causa del problema sono le Security Policy di default su Windows 2003 Server, che sono settate per crittare sempre le connessioni di rete in qualunque caso. Questa crittazione funziona ovviamente bene tra macchine Windows, può funzionare anche verso client samba v.3 che la supportino piegandosi alle pretese di Windows, mentre la versione di SMB di Mac OS X 10.2-10.3 non supporta connessioni criptate.

La soluzione è settare la criptazione perché venga utilizzata solo “quando disponibile”, e non “sempre e comunque”.

1. Su Windows 2003 Server dagli “Administrative Tools” aprire “Domain Controller Security Settings”.
2. Scegliere “Local Policies” a poi “Security Options”.
3. Scrollare in giù fino a trovare la voce “Microsoft network server: Digitally sign communications (always)”
4. Impostare questa voce a “Disabled”
5. Chiudere il tool di amministrazione, e per applicare le policy aprire una Command shell (Start -> Run -> “cmd”) e digitare:
   gpupdate (Invio)
   Al termine dell’esecuzione dovrebbe dare conferma che le policy sono state applicate

Il problema delle policy è risolto, quindi salvo problemi dovuti ad altro ora dovremmo essere in grado di accedere agli share di Windows 2003 Server.