NAS Dell Unity + Samba4 + commande mount : impossible de monter des partages CIFS
Bonjour, Nous avons un NAS Dell EMC Unity et un contrôleur de domaine samba 4.9 sous Debian GNU/Linux Stretch. À partir d'une machine GNU/Linux (Debian, Ubuntu, plusieurs versions de chaque), nous ne parvenons pas à monter des partages CIFS exportés par le NAS avec la commande « mount ». L'erreur est « mount error(13): Permission denied ». Nous avons tenté de jouer avec l'option « -o sec » et les valeurs NTLM, Kerberos, etc. Sans succès. Il semblerait que le NAS n'interroge pas le samba4 lorsqu'il reçoit les requêtes SMB des machines clientes. En revanche, depuis ces mêmes machines GNU/Linux et le même NAS, un montage CIFS avec GVFS (« gvfs-mount ») fonctionne. Si nous couplons le même NAS avec un Active Directory officiel (pas Samba), un montage CIFS avec « mount » fonctionne parfaitement depuis les mêmes machines clientes GNU/Linux. Du coup, nous sommes un peu perdus : le problème est-il dans les paramètres passés dans les requêtes SMB entre le client et le NAS ou entre le NAS et le samba4 ? Quelqu'un a-t-il réussi à monter des partages CIFS avec la commande mount + un NAS Dell Unity + samba 4 ? Bonne journée.
Bonjour, je ne réponds pas directement à la question car je suis sous environnement purement Windows mais. Il faudrait voir quelle version de CIFS, ou plutôt SMB, votre NAS propose. Si c'est la dernière (3.1.1) il y a de forte chance que seul un AD (2016 au moins) puisse le proposer à vos clients. Par défaut, jusqu’à Windows 2016, SMB proposait toutes les versions aux clients. Depuis 2019 SMB1 n'est plus activé par exemple. De même, AD version 2016 "parle" NTLM toutes versions par défaut. Sauf à le stipuler par GPO. QUID de votre Samba ? QUID de vos clients Linux ? Pour faire "simple", c'est toujours la problématique avec les constructeurs, NetAPP ne faisant exception, on ne sait jamais, sauf à chercher dans leurs docs, quels sont les versions de protocoles utilisés par les NAS. -- Cordialement, Philippe Le 03/10/2019 à 11:10, Guillaume LUCAS a écrit :
Bonjour,
Nous avons un NAS Dell EMC Unity et un contrôleur de domaine samba 4.9 sous Debian GNU/Linux Stretch.
À partir d'une machine GNU/Linux (Debian, Ubuntu, plusieurs versions de chaque), nous ne parvenons pas à monter des partages CIFS exportés par le NAS avec la commande « mount ». L'erreur est « mount error(13): Permission denied ». Nous avons tenté de jouer avec l'option « -o sec » et les valeurs NTLM, Kerberos, etc. Sans succès. Il semblerait que le NAS n'interroge pas le samba4 lorsqu'il reçoit les requêtes SMB des machines clientes.
En revanche, depuis ces mêmes machines GNU/Linux et le même NAS, un montage CIFS avec GVFS (« gvfs-mount ») fonctionne.
Si nous couplons le même NAS avec un Active Directory officiel (pas Samba), un montage CIFS avec « mount » fonctionne parfaitement depuis les mêmes machines clientes GNU/Linux.
Du coup, nous sommes un peu perdus : le problème est-il dans les paramètres passés dans les requêtes SMB entre le client et le NAS ou entre le NAS et le samba4 ?
Quelqu'un a-t-il réussi à monter des partages CIFS avec la commande mount + un NAS Dell Unity + samba 4 ?
Bonne journée. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
bonjour en essayant l'option "-o vers" dans le mount pour forcer la version en essayant différentes versions proposées dans le man mount.cifs cordialement On 03/10/2019 11:50, Philippe Beauchet wrote:
Bonjour,
je ne réponds pas directement à la question car je suis sous environnement purement Windows mais.
Il faudrait voir quelle version de CIFS, ou plutôt SMB, votre NAS propose. Si c'est la dernière (3.1.1) il y a de forte chance que seul un AD (2016 au moins) puisse le proposer à vos clients.
Par défaut, jusqu’à Windows 2016, SMB proposait toutes les versions aux clients. Depuis 2019 SMB1 n'est plus activé par exemple.
De même, AD version 2016 "parle" NTLM toutes versions par défaut. Sauf à le stipuler par GPO.
QUID de votre Samba ? QUID de vos clients Linux ?
Pour faire "simple",
c'est toujours la problématique avec les constructeurs, NetAPP ne faisant exception, on ne sait jamais, sauf à chercher dans leurs docs, quels sont les versions de protocoles utilisés par les NAS.
-- Laurent NIETO Pôle systèmes et réseau Direction des Systèmes d'Information Ecole Centrale de Lyon 36 avenue Guy de Collongue 69134 Ecully Cedex tel: +33 (0)04 72 18 60 80 Horaires accueil DSI de 10h30 à 12h30 les Lundi - Mercredi - Vendredi de 13h30 à 15h30 les Mardi - Jeudi https://dsi.ec-lyon.fr/
Le 03/10/2019 à 11:50, Philippe Beauchet a écrit :
Il faudrait voir quelle version de CIFS, ou plutôt SMB, votre NAS propose. Si c'est la dernière (3.1.1) il y a de forte chance que seul un AD (2016 au moins) puisse le proposer à vos clients.
Pourquoi ?
Par défaut, jusqu’à Windows 2016, SMB proposait toutes les versions aux clients. Depuis 2019 SMB1 n'est plus activé par exemple.
Oui, pour des raisons de sécurité.
QUID de votre Samba ? QUID de vos clients Linux ?
Bon point. Difficile à vérifier côté client quand « mount » ne fonctionne pas alors que GVFS fonctionne, car ça suppose une prise en charge différente dans deux endroits (lib, module noyau) d'un même système… Je ne sais pas trop où chercher cette info, du coup…
Le 03/10/2019 à 15:58, Guillaume LUCAS a écrit :
Le 03/10/2019 à 11:50, Philippe Beauchet a écrit :
Il faudrait voir quelle version de CIFS, ou plutôt SMB, votre NAS propose. Si c'est la dernière (3.1.1) il y a de forte chance que seul un AD (2016 au moins) puisse le proposer à vos clients.
Pourquoi ?
Et bien non. Apparemment Samba le supporte finalement. https://fr.wikipedia.org/wiki/Samba_(informatique) Désolé je ne connais pas ce monde.
Par défaut, jusqu’à Windows 2016, SMB proposait toutes les versions aux clients. Depuis 2019 SMB1 n'est plus activé par exemple.
Oui, pour des raisons de sécurité.
Oui je suis d'accord. Bien qu'il l'ai patché depuis mais bon. https://docs.microsoft.com/fr-fr/security-updates/SecurityBulletins/2017/ms1...
QUID de votre Samba ? QUID de vos clients Linux ?
Bon point. Difficile à vérifier côté client quand « mount » ne fonctionne pas alors que GVFS fonctionne, car ça suppose une prise en charge différente dans deux endroits (lib, module noyau) d'un même système… Je ne sais pas trop où chercher cette info, du coup...
Un peu partout. Surtout dans le monde Linux, mais cela est chronophage. Quelques méthodes, avec du Windows, pour détecter quelle version votre NAS "parle". https://www.it-connect.fr/quelle-version-du-protocole-smb-utilisez-vous/ https://support.microsoft.com/fr-fr/help/2696547/detect-enable-disable-smbv1... Désactivez chaque version sur votre poste et vous verrez si il répond toujours à votre NAS. Mais si, moyennant quelques lib ou modules noyau (gérable avec des softs comme ansible ou puppet ?) GVFS marche, pourquoi vous tracasser ? Mes 2cts, sinon il ne reste qu'a demander à DELL de vous fournir un Firmware adéquat. Du genre SMB2, qui est bien pris en charge par tout le monde (relativement récent) maintenant.
Bonjour tout le monde, Je ne comprends pas pourquoi on cherche à continuer avec CIFS/SMB (hello Wannacry/NotPetya) alors que même Windows supporte NFS ... Quelle est la raison de ne pas vouloir simplifier les choses et utiliser un protocole qui fonctionne partout sans être une plaie ? https://docs.microsoft.com/en-us/windows-server/storage/nfs/nfs-overview Ensuite GVFS vs mount, tu as cette réponse qui te dit la différence : https://askubuntu.com/a/926451 On Thu, Oct 3, 2019, 09:24 Philippe Beauchet <philippe.beauchet@map.cnrs.fr> wrote:
Le 03/10/2019 à 15:58, Guillaume LUCAS a écrit :
Le 03/10/2019 à 11:50, Philippe Beauchet a écrit :
Il faudrait voir quelle version de CIFS, ou plutôt SMB, votre NAS propose. Si c'est la dernière (3.1.1) il y a de forte chance que seul un AD (2016 au moins) puisse le proposer à vos clients.
Pourquoi ?
Et bien non. Apparemment Samba le supporte finalement.
https://fr.wikipedia.org/wiki/Samba_(informatique)
Désolé je ne connais pas ce monde.
Par défaut, jusqu’à Windows 2016, SMB proposait toutes les versions aux clients. Depuis 2019 SMB1 n'est plus activé par exemple.
Oui, pour des raisons de sécurité.
Oui je suis d'accord. Bien qu'il l'ai patché depuis mais bon.
https://docs.microsoft.com/fr-fr/security-updates/SecurityBulletins/2017/ms1...
QUID de votre Samba ? QUID de vos clients Linux ?
Bon point. Difficile à vérifier côté client quand « mount » ne fonctionne pas alors que GVFS fonctionne, car ça suppose une prise en charge différente dans deux endroits (lib, module noyau) d'un même système… Je ne sais pas trop où chercher cette info, du coup...
Un peu partout. Surtout dans le monde Linux, mais cela est chronophage.
Quelques méthodes, avec du Windows, pour détecter quelle version votre NAS "parle".
https://www.it-connect.fr/quelle-version-du-protocole-smb-utilisez-vous/
https://support.microsoft.com/fr-fr/help/2696547/detect-enable-disable-smbv1...
Désactivez chaque version sur votre poste et vous verrez si il répond toujours à votre NAS.
Mais si, moyennant quelques lib ou modules noyau (gérable avec des softs comme ansible ou puppet ?) GVFS marche, pourquoi vous tracasser ?
Mes 2cts, sinon il ne reste qu'a demander à DELL de vous fournir un Firmware adéquat. Du genre SMB2, qui est bien pris en charge par tout le monde (relativement récent) maintenant. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 03/10/2019 à 17:04, Florent CARRÉ a écrit :
Je ne comprends pas pourquoi on cherche à continuer avec CIFS/SMB (hello Wannacry/NotPetya) alors que même Windows supporte NFS ...
Je doute qu'il y ait une prise en charge identique d'un point de vue fonctionnel, notamment sur la gestion des droits, sur la possibilité de monter le profil des utilisateurs en NFS, etc.
Quelle est la raison de ne pas vouloir simplifier les choses et utiliser un protocole qui fonctionne partout sans être une plaie ?
NFS ne serait pas une plaie ? Je passe mon tour. En ce qui nous concerne, la raison est : isopérimètre. Là, nous voulons juste changer notre NAS, pas remettre en cause XXXX autres éléments de notre infra. Chaque élément en son temps.
Ensuite GVFS vs mount, tu as cette réponse qui te dit la différence : https://askubuntu.com/a/926451
Notre samba est en SMB3_11, comme notre NAS. On a déjà joué avec mount + « -o vers », sans succès. Et nous, GVFS fonctionne, mais pas mount. On a aussi tenté de changé la version de SMB de notre NAS. Sans succès. Il prend en charge entre SMBv2.02 et SMBV3.11… J'ai tenté « client max protocol = SMB3 » et « client min protocol = SMB2 » dans le smb.conf de la machine cliente. Sans succès.
Bonjour, sans polémiques, Le 03/10/2019 à 17:04, Florent CARRÉ a écrit :
Bonjour tout le monde,
Je ne comprends pas pourquoi on cherche à continuer avec CIFS/SMB (hello Wannacry/NotPetya) alors que même Windows supporte NFS ...
Quelle est la raison de ne pas vouloir simplifier les choses et utiliser un protocole qui fonctionne partout sans être une plaie ?
https://docs.microsoft.com/en-us/windows-server/storage/nfs/nfs-overview
NFS sur Windows...laissez tomber. On à essayé (2012) et franchement... Déjà qu'il est incapable de gérer les UID, pas très grave mais chia... A voir avec 2019 mais bon. Wannacry et Cie c'est une chimère...pour qui administre correctement son parc Windows. Chez nous cela faisait un bail que SMB1 était désactivé par exemple. Bon je ne cherche pas de polémiques mais des Windows bien gérés (on sort du débat) cela se fait sans soucis particuliers. Comme les Linux. Comme le dit un collègue, du monde Linux: "Le meilleur système est celui que l'on administre le mieux." -- Confraternellement, Philippe
Le 03/10/2019 à 16:22, Philippe Beauchet a écrit :
Désactivez chaque version sur votre poste et vous verrez si il répond toujours à votre NAS.
Downgrade un poste Windows ? Pourquoi pas. Jusque-là, nous avons tenté les différentes versions de SMB sur le poste client GNU/Linux. Aborder le problème par l'autre face pourrait être intéressant.
Mais si, moyennant quelques lib ou modules noyau (gérable avec des softs comme ansible ou puppet ?) GVFS marche, pourquoi vous tracasser ?
Dépendance à GNOME. La stabilité / fiabilité de GVFS m'est inconnue. Intégration à refaire (car on veut rendre le contenu accessible depuis un chemin précis et existant), en prenant en compte le chemin GVFS basé sur un nombre environ aléatoire (en sus de l'UID, prévisible, lui).
sinon il ne reste qu'a demander à DELL de vous fournir un Firmware adéquat. Du genre SMB2, qui est bien pris en charge par tout le monde (relativement récent) maintenant.
L'interface web du NAS permet de choisir la version de SMB dans la plage SMB v2.02 - SMB 3.11. Évidemment, ça ne fonctionne pas.
Mes culpa pour la polémique qui n'était pas le but Un script python qui fait un check de version, ça peut aider : https://github.com/amitn322/smb-version (Il fait un smbclient et analyse le paquet raw) GVFS utilise la libsmbclient et surtout "mount.cifs ignores smb.conf completely" As-tu une sortie du style : "[ 6098.304184] CIFS VFS: cifs_mount failed w/return code = -5" ? Quelle est la version : - de la distrib linux - du kernel - du package cifs-utils - du package samba - du package libsmbclient Je pense qu'il faut creuser plus en profondeur dans les versions des packages et peut être trouver une issue déjà existante sur le sujet Il y avait eu un problème similaire sur boot2docker.iso (tinycorelinux) mais c'était il y a 4 ans On Fri, Oct 4, 2019, 05:26 Guillaume LUCAS <guillaume.lucas@univ-avignon.fr> wrote:
Le 03/10/2019 à 16:22, Philippe Beauchet a écrit :
Désactivez chaque version sur votre poste et vous verrez si il répond toujours à votre NAS.
Downgrade un poste Windows ? Pourquoi pas. Jusque-là, nous avons tenté les différentes versions de SMB sur le poste client GNU/Linux. Aborder le problème par l'autre face pourrait être intéressant.
Mais si, moyennant quelques lib ou modules noyau (gérable avec des softs comme ansible ou puppet ?) GVFS marche, pourquoi vous tracasser ?
Dépendance à GNOME. La stabilité / fiabilité de GVFS m'est inconnue. Intégration à refaire (car on veut rendre le contenu accessible depuis un chemin précis et existant), en prenant en compte le chemin GVFS basé sur un nombre environ aléatoire (en sus de l'UID, prévisible, lui).
sinon il ne reste qu'a demander à DELL de vous fournir un Firmware adéquat. Du genre SMB2, qui est bien pris en charge par tout le monde (relativement récent) maintenant.
L'interface web du NAS permet de choisir la version de SMB dans la plage SMB v2.02 - SMB 3.11. Évidemment, ça ne fonctionne pas. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour à tous, Celle fonctionne, désormais. Il fallait un fichier /etc/krb5.conf sur les machines clientes GNU/Linux… Pas besoin d'en faire des tonnes, juste : [libdefaults] default_realm = AD.UNIV-AVIGNON.FR [realms] AD-UNIV-AVIGNON.FR = { kdc = ad01c.ad.univ-avignon.fr […] } Après, il faut « kinit », puis « mount -o sec=krb5 […] ». Sur certaines machines, il faut préciser « vers=3.0 ». Nous avions bien positionné un fichier /etc/krb5.conf avant que je vous sollicite, mais il devait être incomplet / invalide / autre. Vos réponses, qui convergeaient vers un problème de version ou de protocole d'auth divergeant entre les clients winwin et les clients GNU/Linux, nous ont ouvert les yeux. Ce qui m'échappe encore, c'est la manière de procéder de GVFS. En toute logique, il ne peut pas détenir un ticket Kerberos valide sans un fichier krb5.conf bien positionné. Bascule-t-il sur NTLM ? Si oui, cause-t-il mieux NTLM que la commande mount ? D'après l'intervenant Dell (nous avions effectué un jour de prestation sur ce problème avant que je vous sollicite, mais je n’en avais pas le compte-rendu lorsque je vous ai envoyé mon premier email), les machines winwin 10 et GVFS utilisent Kerberos d'après les journaux du NAS… Mais alors, comment GVFS fait-il sans fichier de conf' Kerberos ?! Bref, éternelle question… Merci pour le coup de patte. Bonne soirée. De: "Florent CARRÉ" <colundrum@gmail.com> À: frsag@frsag.org Envoyé: Vendredi 4 Octobre 2019 13:17:17 Objet: Re: [FRsAG] NAS Dell Unity + Samba4 + commande mount : impossible de monter des partages CIFS Mes culpa pour la polémique qui n'était pas le but Un script python qui fait un check de version, ça peut aider : [ https://github.com/amitn322/smb-version | https://github.com/amitn322/smb-version ] (Il fait un smbclient et analyse le paquet raw) GVFS utilise la libsmbclient et surtout "mount.cifs ignores smb.conf completely" As-tu une sortie du style : "[ 6098.304184] CIFS VFS: cifs_mount failed w/return code = -5" ? Quelle est la version : - de la distrib linux - du kernel - du package cifs-utils - du package samba - du package libsmbclient Je pense qu'il faut creuser plus en profondeur dans les versions des packages et peut être trouver une issue déjà existante sur le sujet Il y avait eu un problème similaire sur boot2docker.iso (tinycorelinux) mais c'était il y a 4 ans On Fri, Oct 4, 2019, 05:26 Guillaume LUCAS < [ mailto:guillaume.lucas@univ-avignon.fr | guillaume.lucas@univ-avignon.fr ] > wrote: Le 03/10/2019 à 16:22, Philippe Beauchet a écrit :
Désactivez chaque version sur votre poste et vous verrez si il répond toujours à votre NAS.
Downgrade un poste Windows ? Pourquoi pas. Jusque-là, nous avons tenté les différentes versions de SMB sur le poste client GNU/Linux. Aborder le problème par l'autre face pourrait être intéressant.
Mais si, moyennant quelques lib ou modules noyau (gérable avec des softs comme ansible ou puppet ?) GVFS marche, pourquoi vous tracasser ?
Dépendance à GNOME. La stabilité / fiabilité de GVFS m'est inconnue. Intégration à refaire (car on veut rendre le contenu accessible depuis un chemin précis et existant), en prenant en compte le chemin GVFS basé sur un nombre environ aléatoire (en sus de l'UID, prévisible, lui).
sinon il ne reste qu'a demander à DELL de vous fournir un Firmware adéquat. Du genre SMB2, qui est bien pris en charge par tout le monde (relativement récent) maintenant.
L'interface web du NAS permet de choisir la version de SMB dans la plage SMB v2.02 - SMB 3.11. Évidemment, ça ne fonctionne pas. _______________________________________________ Liste de diffusion du FRsAG [ http://www.frsag.org/ | http://www.frsag.org/ ] _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
participants (4)
-
Florent CARRÉ -
Guillaume LUCAS -
laurent.nieto＠ec-lyon.fr -
Philippe Beauchet