MacBook avec réseau Windows

LaurentA33

Membre enregistré
13 Mars 2017
5
0
36
Bonjour,

"Panique à bord!! Les femmes et les mac d'abord!"


Je m'explique :

J'ai un parc de 30 PC sous Windows XP/7/8/8.1/10/vista(dsl) Et un lot d'une petite demi-douzaine d’imprimante.
Au niveau des accès réseaux : j'ai un disque sur un serveur.
Mon IP de serveur est la 192.168.0.20, le partage s'appelle "Datas" , ce serveur s'appel Neo ( Oui, comme dans matrix)
Maintenant, dans tout ça je viens ajouter un MacBook Pro OS x10.9.

1) Des fichiers .DS_Store apparaissent partout. Quand je dis partout, c'est partout ! Dans chaque dossier de ce lecteur réseau.
J'ai vu sur le net qu'on pouvais interdire au Mac de créer ce fichier.
SOIT! Visiblement il n'y en a plus qu'un seul sur le serveur depuis. A la racine de ce \\192.168.0.20\Datas

Le vrai problème n'es pas la. Parce que sinon ce serai trop simple!

2) Ce Mac n'es pas toujours allumé, et par toujours sur le réseau.
Et au démarrage du MACbook c'est .... INCROYABLEMENT LONG avant de pouvoir lancer le lecteur "Datas".
Qu-entend-je par incroyable? On parle d'environ UNE heure!
Alors qu'il ping très bien ce serveur Neo et que son IP est correct (Elle est fixe a 192.168.0.186)

Ce que j'ai constaté :
- Visiblement dans le finder dans l'onglet "partagé" je constate que le MAC fait des essai de connexion sur une partie des machine connecté au réseau local (Pas toutes! mais certaine environ 15) Et vu qu'il n'a pas d'identifiant sur ces bécane forcement il est en erreur et donc prend du temps.
- Le fichier .DS_Store a la racine de mon disque est impossible a supprimer

De plus l'espace disponible sur ce Datas n'es pas à jour au début. L'espace disponible ne sera à jour que si le serveur est connecté.

Alors du coup je lance une bouée dans votre direction. Mes nombreuses recherches n'ayant jusqu'alors trouvée aucune réponse.

N’hésitez pas si vous avez des questions pour m'aider sur ce soucis! :)

Merci.
 
Bonjour,

Est ce que le disque de démarrage du MacBook est bien sélectionné ?
(Préférences système / démarrage / un clic sur le dd interne)
 
Bonjour,

Alors Oui.
Le Mac en lui même fonctionne très bien et demarre relativement vite s'il est "hors reseau" ;)
 
Dernière édition par un modérateur:
La question de Sly54 n'est pas anodine : si le Mac choisit son volume de démarrage selon le contexte, il peut se comporter très bien hors réseau (parce que pas le choix, seulement le DD interne), mais chercher pendant des heures quand un réseau traîne dans le coin. Il convient alors de bien lui indiquer que quoi qu'il arrive il doit démarrer sur le DD interne.

Éventuellement, gagnes-tu du temps si tu démarres sur la toche alt et que tu le forces à prendre le chemin du DD interne ?
 
La séquence de démarrage du Mac (il vaut mieux écrire "Mac" pour un Mac, plutôt que "MAC", qui désigne l'identifiant unique de chaque carte réseau (virtuelle ou physique) d'un ordinateur) écrit de nombreux messages dans les journaux du système ; tous ces messages sont horodatés.
Tu pourrais donc commencer par regarder dans ces journaux les messages liés au démarrage, avec l'utilitaire Console, qui permet de voir tous les messages que générent le système et les applications, dans l'ordre chronologique, en totalité ou par section, filtrés ou non par des requêtes etc.

Il te suffit de repérer le moment où tu as démarré l'ordinateur et d'éplucher les messages de cette période.
Tu peux même comparer entre un démarrage vif (hors réseau) et un démarrage mou (connecté au réseau) et voir ainsi où le temps est perdu.

Par ailleurs, quand tu parles de démarrage, c'est avec l'ouverture de session, ou simplement jusqu'à la mire de login ?
 
Bonjour,

Ça commence mal avec un Macbook Pro en version Maverick (10.9).
Apple a eu la bonne idée de "ré-développer" le protocole SMB afin d'éviter de payer une licence.
Et sur Mavericks, ca ne marche tout bonnement pas.
Il faut forcer la connexion en cifs
Bloc de code:
cifs://adresse_ip_serveur/point_de_partage
Vous pouvez également contraindre le MacBook a n'utiliser que la version 1 du protocole SMB en créant au niveau /etc/ un fichier nommé nsmb.conf et en y inscrivant ceci :
Bloc de code:
smb_neg=smb1_only
streams=no
file_ids_off=yes
notify_off=no
Le fichier doit avoir les permissions root:wheel
Bloc de code:
chown root:wheel /etc/nsmb.conf
Redémarrez la station

Pour éviter ces fameux .DSstore, lancer le Terminal et taper la commande suivante :
Bloc de code:
defaults write com.apple.desktopservices DSDontWriteNetworkStores true
Valider puis redémarrez la station.

Pour les supprimer , se placer sur le point de partage et :
Bloc de code:
sudo find / -name ".DS_Store" -depth -exec rm {} \;
 
Bonjour,

Alors en effet cette solution me semble être une bonne idée.
Dès que le Mac repasse sur mon bureau je regarde ça attentivement!

Je vous tiendrais bien évidement au courant (Le Mac et son proprio sont en déplacement pour la semaine ;) )

concernant la commande
Bloc de code:
defaults write com.apple.desktopservices DSDontWriteNetworkStores true
J'ai déjà essayé ;) Les I-phone's produisent-ils également ces fichiers?

Merci en tout cas ;)
 
Petite précision : la commande
Bloc de code:
sudo find / -name ".DS_Store" -depth -exec rm {} \;
va supprimer tous les fichiers .DS_Store de l'ordinateur sur lequel tu la lances, car tu pars de la racine (/) et parcours la totalité des répertoires, volumes montés compris.
Peut-être faudrait-il changer le premier paramètre de la commande find par un chemin de départ plus restrictif.
Par ailleurs, il est préférable de grouper les commandes de suppression, pour gagner du temps, ce que l'on peut réaliser en utilisant un plus (+) au lieu du point-virgule (;).
Ce qui nous donne quelque chose comme :
Bloc de code:
sudo find /chemin_de_depart -name ".DS_Store" -depth -exec rm {} +
 
la commande : sudo find / -name ".DS_Store" -depth -exec rm {} \; va supprimer tous les fichiers .DS_Store de l'ordinateur sur lequel tu la lances, car tu pars de la racine (/) et parcours la totalité des répertoires, volumes montés compris.

Comme tu le mentionnes > la commande find portant sur / globalement > va effectivement traverser le répertoire /Volumes > et au cas où une série de n autres volumes (Système ou Stockage) s'y trouvent montés en équivalents-dossiers > elle va descendre dans ces "dossiers de volumes montés" dans /Volumes. Par suite > la commande associée à find via -exec (rm ici) va s'appliquer aussi à tous les éléments trouvés dans l'espace des "dossiers de volumes montés" dans /Volumes. Ce qui peut s'avérer critique.

En liant directement à find l'option -x > interdisant de descendre dans des répertoires qui ont un numéro de device autre que celui du répertoire parent (= /Volumes) > la recherche dans le répertoire /Volumes n'entre pas alors dans les "dossiers de volumes montés" . Ce qui donnerait une commande :
Bloc de code:
sudo find -x / -name '.DS_Store' -depth -exec rm {} +
 
Dernière édition par un modérateur:
Je n'ai peut-être pas bien suivi mais, si j'ai bien compris, il s'agit de ne pas polluer un partage réseau SMB/CIFS, lequel n'est pas sur le Mac mais accédé depuis le Mac.

Tant que l'on s'attache à démarrer la recherche, donc la suppression, à la racine du système, on va supprimer des fichiers .DS_Store que l'on aimerait sans doute conserver. Il faut bien démarrer la recherche depuis le dossier sur lequel est monté le volume CIFS, ou l'indiquer dans la commande.
Soit :
Bloc de code:
sudo find "/chemin_de_depart" -name ".DS_Store" -depth -exec rm {} +
Soit :
Bloc de code:
cd "/chemin_de_depart"
sudo find . -name ".DS_Store" -depth -exec rm {} +
où "/chemin_de_depart" est le chemin menant au point de montage.

Note : quand bien même le partage aurait sa source sur le Mac pour le proposer à des machines sous Ouinedoze, la problématique resterait la même : on souhaite que le Mac ne pollue pas un dossier (et ses sous-dossiers) auquel accèdent des systèmes qui ne comprennent que couic à un .DS_Store. Il s'agit alors de nettoyer uniquement la partie partagée, pas la totalité du Mac.
 
Je n'ai peut-être pas bien suivi mais, si j'ai bien compris, il s'agit de ne pas polluer un partage réseau SMB/CIFS, lequel n'est pas sur le Mac mais accédé depuis le Mac.

Et tu a tout a fait bien compris ;)

Tant que l'on s'attache à démarrer la recherche, donc la suppression, à la racine du système, on va supprimer des fichiers .DS_Store que l'on aimerait sans doute conserver. Il faut bien démarrer la recherche depuis le dossier sur lequel est monté le volume CIFS, ou l'indiquer dans la commande.

La différence étant que, honte sur moi, je supprime les .DS_Store depuis Ouinedoze ( :p )
Et effectivement, je le les supprimes que sur les espaces partagé visible depuis le mac.

Ce que je trouve bizarre c'est dans le menu réseau à gauche dans le finder... quand j'allume le MAC j'ai l’impression qu'il essai de se connecté à un lot de PC de mon réseau (Mais pas tous) Ce serait lié au groupe de travail peut être? La suite quand le Mac reviens des States ;)

Merci pour toutes vos pistes en tout cas! Je ne manquerais pas de vous tenir informés dès que j'avance la dessus.