NAS Synology + AFP + SMB + TimeMachine

Daffy44

Membre actif
30 Novembre 2011
282
21
54
Nantes
Hello tous,

Je croyais le problème ailleurs et j'ai tout remis à zéro sur mon NAS (formatage des unités réinstallation "from scratch") hélas non...
Après investigation et cela sur 3 sites distincts (1 avec un DS412+ et deux avec un DS414) je reproduis le problème suivant.

Si j'active (comme c'est le cas par défaut) les protocoles SMB et AFP, mes appareils se connectent sans difficultés. Par ailleurs sur mes Mac le Finder voit le NAS et s'y connecte par défaut via le protocole AFP. Je peux forcer une connection SMB mais en natif AFP est plus rapide et plus stable. Bref tout baigne !

Si je décide de choisir le dossier du NAS pour TimeMachine, alors je ne peux plus faire de connection "native" via le Finder sur le NAS. Je suis obligé de "forcer" la connection via le menu "se connecter au serveur" du Finder et saisir afp://adresse du NAS pour accéder aux partages sous ce protocole.

Mon NAS apparaît toujours dans les appareils partagés mais en SMB et je ne peux me connecter à ce dernier sauf à repasser en SMB et perdre les montages AFP présents. (qui plus est souvent alors, la connection en SMB est lente et instable).

A dire ou à écrire c'est compliqué.. alors j'ai fait une petite vidéo pour démontrer ma problématique. (sujet remonté auprès de Synology).

Ma question est la suivante : suis-je seul sur 3 NAS dans 3 environnements distincts à avoir ce problème ?

Il va de soit que :

avant DSM6 ce problème n'existait pas / Il me faut bien les 2 protocoles ET TimeMachine sur le NAS (les PCs ne sont pas impactés par cette problématique).

J'ai tenté de changer les niveaux SMB, d'ôter IPV6, de vider le cache etc.. rien n'y fait.
 
Bonjour,

Quel utilisateur utilisez vous pour le point de partage TimeMachine sur le Synology ?
Est ce votre propre compte ?
Si oui, tentez de créer un utilisateur dédié au point de partage TimeMachine, tmuser par exemple (l'avantage de créer un utilisateur séparé permet de mettre un quota à TimeMachine, qui, sans cela, a une fâcheuse tendance à envahir le disque).
Est ce que votre problème est toujours là ?
Pour ma part, je gère une dizaine de NAS de ce type (dernière version DSM) et je ne rencontre pas ce problème. Mais j'ai un utilisateur différent pour TimeMachine et les autres points de partage
 
Bonjour,
C'est aussi mon cas :
Un user pour les partages montés en afp dans le Finder
Un user (avec quota bien sûr) pour la TM.

même situation sur 3 sites avec 2 ds414 et 1 ds412+

Chez vous lorsque les montages des dossiers partages sont faits ils le sont en afp ou en smb.
Si oui, alors lorsque vous parcourez (toujours depuis le Finder) le réseau puis le NAS les partages proposés sont en afp ou en smb ?
 
Il serait utile de préciser l'OS car l'interprétation du protocole SMB "by Apple" varie depuis la version 10.9 (Mavericks) !
Pour ma part, j'utilise El Capitan (10.11.5) (qui privilégie par défaut le protocole smb 3, afp étant amené à disparaitre (un jour dixit Apple)). Mes points de montage (browse) sont donc nativement montés en smb (smb1 pour ma part grace à la création d'un fichier nsmb.conf au niveau du répertoire etc/)
Que donne la commande suivante
Bloc de code:
smbutil statshares -a
 
Pour complément, voici mon fichier nsmb.conf :
Bloc de code:
# Fichier de configuration /private/etc/nsmb.conf

[default]
signing_required=no
smb_neg=smb1_only
streams=no
minauth=ntlmv2
notify_off=yes
port445=no_netbios
file_ids_off=yes

Les permissions du fichier doivent être root:wheel
Le fichier est à placer dans le répertoire /etc/ à la racine. Reboot obligatoire pour prise en compte
 
Oui afp doit disparaître.
Sauf que nativement si une machine propose de l'AFP alors les montages peuvent se faire.
Chez moi le smb a souvent été bancale et moins rapide que ce bon vieil afp.
Ceci étant merci pour ces infos, je vais regarder cela de près.
Pourquoi en smb1 et non 3.
Enfin toutes machines sont en 10.11.5
 
Bonjour,

Vous avez raison. Le smb proposé par Apple est en effet "bancal". Apple a préféré le mettre à sa sauce et le redévelopper pour son système plutôt que de payer une licence :mad: ... avec le succès que l'on sait.
Nous utilisons le smb1 car c'est le plus stable aujourd'hui ... mais aussi le plus lent.
Vous pouvez changer le paramètre de négociation "smb_neg" dans le fichier nsmb.conf.
Bloc de code:
smb_neg=normal
Bloc de code:
smb_neg=smb1_only
Bloc de code:
smb_neg=smb2_only
Vous pouvez trouver ces informations (+ détaillées) en tapant dans le terminal
Bloc de code:
man nsmb.conf
 
Super merci pour ces infos. Personnellement je préfère rester en afp c'est plus performant pour l'heure. Ceci dit je regarderai de près toutes ces informations merci.
 
Avec MacOS 10.12.2, et un Synology 6.0.2-8451-update 7, la lenteur en utilisant SMB est chaotique. En utilisant AFP c'est acceptable.
Dans un réseau GB, en copiant un fichier de 4 GB, depuis AFP cela prends 18 secondes et avec SMB cela prend 1.20 minute.
Je recherche une solution pour qu'on puisse utiliser un protocole fiable et rapide pour les Mac en réseau.
Il semble que depuis que Tim Cook est au pouvoir, toute la philosophie de Steve Jobs est en train de disparaître.
 
Dernière édition par un modérateur:
Avec MacOS 10.12.2, et un Synology 6.0.2-8451-update 7, la lenteur en utilisant SMB est chaotique. En utilisant AFP c'est acceptable.
Dans un réseau GB, en copiant un fichier de 4 GB, depuis AFP cela prends 18 secondes et avec SMB cela prend 1.20 minute.
Je recherche une solution pour qu'on puisse utiliser un protocole fiable et rapide pour les Mac en réseau.
Il semble que depuis que la pédale de Tim Cook est au pouvoir, toute la philosophie de Steve Jobs est en train de disparaître.

Classe!...
 
L'OS de Synology y serait il aussi pour quelque chose ?
L'expérience a t elle été tentée avec d'autres marques ?

afp est donc présent pour des questions de rétro compatibilité mais il est voué a disparaitre, de plus la cohabitation avec smb est pas terrible ? j'ai bien compris ?
 
faudrait essayer en SMB2 et SMB3 pour voir ce que ça change (si ça change quelque chose d'ailleurs)
 
Vous pouvez changer le paramètre de négociation "smb_neg" dans le fichier nsmb.conf.
Avec la version 10.12.x ce paramètre n'est plus d'actualité.
Il faut le remplacer par
Bloc de code:
protocol_vers_map
avec la valeur 7 pour smb 1/2/3 activé, la valeur 6 pour smb 2/3 activé et 4 pour activer seulement smb 3.
Donc pour etre compatible smb 1, 2, 3 il vous faudra remplacer smb_neg par :
Bloc de code:
protocol_vers_map=7
 
J'ai fait un petit essai dernièrement :
Un NAS Syno 4 baies et un MacBook Pro 2009 avec Sierra et un SSD, le tout connecté en gigabyte
En AFP presque 100Mo/s
En SMB 1 (réglage réalisé sur le NAS) 25Mo/s
En SMB 2 (réglage réalisé sur le NAS) 20Mo/s
En SMB 3 (réglage réalisé sur le NAS) 15Mo/s
Ce sont des valeurs indicatives, rien de plus.
 
Dernière édition:
  • J’aime
Réactions: kaos
Bonjour,

Voici un outil (gratuit) permettant de réaliser des tests de vitesses de transfert sur un lan sur des points de partage. Vous trouverez sa description et le lien de téléchargement ici.
 
  • J’aime
Réactions: diablouf44 et kaos
Merci beaucoup pour Hélios !

Je ne manquerais pas de faire des tests sur mes différents serveurs une fois rentré chez moi.

En tout cas, avec "Open Média Vault" et en smb ça tabasse, et c'est effectivement différent sur mes NAS constructeurs
comme Netgear ou D-link ou on se rapproche des valeurs données par Daffyb (en un peu mieux chez moi de mémoire)

Une app est d’ailleurs dispo sur le portail Netgear et elle se nomme "smb+" je crois et permet justement le smb1 smb2 etc ...
je l'ai installé mais pas activé.
 
Bonjour, j'ai exactement les mêmes soucis que ceux énoncés par @Daffy44 voilà plus d'un an et ce malgré les récentes mises à jour de DSM (6.1.3) et de MacOS (10.12.6). Avez-vous pu résoudre vos soucis ?

En ce qui me concerne je soupçonne mon routeur (un TP-LINK TL-MR3420) qui me sert de relais wifi (donc bridgé) d'en être la cause. En effet en passant directement par le wifi de ma box je n'ai aucun souci de détection du disque de sauvegarde situé sur mon NAS par TimeMachine et les sauvegardes s'effectuent normalement. Par contre en passant par le routeur ni TM ni le Finder ne trouvent le disque, je suis obligé de passer par l'IP du NAS via l'interface de connexion serveur du Finder. Cela ressemble à une mauvaise implémentation de Bonjour non ? Je n'arrive pas à trouver de documentation sur le sujet, aussi toute aide me sera la bienvenue !

Je poste ce message avant de rebooter mon Mac et tester la config "nsmb.conf" de @lolipale…

En attendant, voici les captures des tests de l'outil d'Helios via SMB et AFP :

125187screen20170728a768215005.jpg


879891screen20170728a768220843.jpg
 
helios_SMB.png

helios_AFP.png

Ya pas à dire, il y a comme un écart !
diablouf44, t'es sur de mériter le WiFi ?
Pour ma part, je n'ai pas la moindre admiration pour TP-Link (c'est étrange, mais ils font les routeurs les moins cher...) ;)
 
Bizarre comme problème effectivement .... je suis curieux.
On peut mettre de coté un problème liés au ports vu que le Tp est en Bridge, c'est donc une utilisation/lecture du type de partage non ou mal gérer par le routeur ?
 
Bonjour,
Je rallume la chaudière avec une excellente recette... (pardon si vous l'aviez déjà) ...
Bonjour,

Je ne sais si cela peut aider en tout cas, j'avais des difficultés avec mes Macs et mon NAS de faire cohabiter les deux protocoles SMB et AFP. In fine j'avais abandonné et j'utilisais AFP.
si par malheur je montais un dossier en SMB au pire tous les partages existants en AFP sautaient... au mieux j'avais une connexion SMB lente et/ou instable...

Vous savez quoi... toujours pas corrigé par  sur macOS HighSierra...
En tout cas cette solution marche et j'en suis totalement satisfait, si ça peut aider...

La problématique vient du fait que  ne gère pas bien le protocole SMB et surtout l'aspect sécuritaire de signature.
En désactivant cela, du coup la connexion devient aussi rapide qu'en AFP et cerise sur le gâteau on a les deux protocoles opérationnels
Et la sécurité alors ? cette option n'est à craindre que si on "forwarde" le SMB au delà du réseau local par internet et/ou si le serveur visé exige cela. Dans tous les cas on peut remettre l'option sans pb (puisqu'il s'agit du'n fichier de configuration absent par défaut).
Installer le fichier nsmb.conf dans /etc (il doit contenir l'option par défaut pour ôter la signature concernée)

Il faut ajouter un fichier de paramètrage en /etc nommé nsmb.conf. ce dernier doit contenir les lignes suivantes :
Bloc de code:
[default]
signing_required=no
On peu procéder ainsi (via terminal toujours et en disposant des droits d'administration de la machine concernée bien sur)
Bloc de code:
printf "[default]\nsigning_required=no\n" | sudo tee /etc/nsmb.conf >/dev/null
P
ar la suite si on monte un partage SMB, via terminal si on vérifie l'état de la connexion avec la commande suivante :
Bloc de code:
smbutil statshares -a
on constate que la ligne SIGNING_ON n'est plus présente.
(vous pouvez le faire AVANT et vous verrez que la ligne SIGNING_ON est présente et absente si le fichier de configuration est activé.)

Dès lors, non seulement je peux monter un partage SMB en sus de mes partages AFP réalisés, mais le transfert des fichiers est identique en temps de traitement.

exemple avant/après
557991comparesmb.png


in fine, il suffit de supprimer le fichier pour revenir en situation "comme avant".
Bloc de code:
sudo rm /etc/nsmb.conf


------- ------- ------ ------ ------

Enfin, si votre mac fait office AUSSI de serveur SMB pour des PCs... Il faut modifier les paramètres avec les deux actions suivantes sous Terminal :

sudo defaults write /Library/Preferences/SystemConfiguration/com.apple.smb.server SigningRequired -bool FALSE

sudo /usr/libexec/smb-sync-preferences
Et bien sur pour "défaire" même séquence avec une valeur booléenne à TRUE.



 
  • J’aime
Réactions: daffyb