web-dev-qa-db-fra.com

Echec du montage de CIFS dans Ubuntu 13.10 essayé avec sec = ntlm et sec = ntlmv2

J'ai lu à peu près toutes les questions relatives aux montages cifs et malheureusement, je ne peux pas obtenir une part cifs à monter.

La commande que j'utilise fonctionne depuis une machine Redhat mais pas depuis Ubuntu 13.10 (noyau 3.11.0-15-generic)

La commande que j'utilise est

Sudo mount -t cifs //server01.mycompany.com/archive$/StructuralBiology/RAW-Data /home/rawdata2 -o user=hari.lastname,rw,soft,nosuid,uid=1000,gid=1000

J'ai essayé ceci avec sec=ntlm, sec=ntlmv2 et cela ne fonctionne toujours pas.

La commande cifs échoue avec:

mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

Et dmesg a un message:

[169895.357046] CIFS VFS: cifs_mount failed w/return code = -13
[170370.733123] CIFS VFS: cifs_read_super: get root inode failed

J'ai passé des jours à essayer de trouver une réponse et je ne peux pas: toute aide ou tout indicateur sera grandement apprécié.

kernelmountsambafstabcifs
3
harijay

Il semble donc que les noyaux Linux dans Ubuntu 13.10 peuvent avoir des valeurs par défaut différentes pour le programme mount.cifs.

Je lisais la documentation cifs et il y avait le texte:

vers=
           SMB protocol version. Allowed values are:

           ·   1.0 - The classic CIFS/SMBv1 protocol. This is the default.

           ·   2.0 - The SMBv2.002 protocol. This was initially introduced in Windows Vista Service Pack 1, and
               Windows Server 2008. Note that the initial release version of Windows Vista spoke a slightly different
               dialect (2.000) that is not supported.

           ·   2.1 - The SMBv2.1 protocol that was introduced in Microsoft Windows 7 and Windows Server 2008R2.

           ·   3.0 - The SMBv3.0 protocol that was introduced in Microsoft Windows 8 and Windows Server 2012.

J'ai donc supposé que l'archive $ était un serveur basé sur Microsoft Windows 7 et Windows Server 2008R2.

Donc finalement j'ai eu cette commande (ancienne commande avec vers = 2.1 ajoutée) pour monter le partage

alias mountr2='Sudo mount -t cifs //server01.mycompany.com/archive$/StructuralBiology/RAW-Data /home/rawdata2 -o user=hari.lastname,rw,soft,nosuid,uid=1000,gid=1000,vers=2.1

Le partage est alors monté comme auparavant avec des autorisations de lecture et d'écriture complètes. Malheureusement, cela m'a pris un long moment (deux mois et plus) pour comprendre.

En espérant que le module cifs et le programme mount.cifs puissent générer des messages d'erreur plus utiles et significatifs pour ne pas transformer ce processus en une boîte noire.

2
harijay

J'ai eu ce problème sur divers réseaux nécessitant des services de partage de fichiers samba à partir d'un serveur de fichiers basé sur Ubuntu ou LinuxMint.

Dans tous les cas, alors que le compte samba de l'utilisateur possédait un mot de passe et permettait la navigation (et la manipulation de fichiers) d'un partage via un gestionnaire de fichiers, les montages fstab ne fonctionnaient pas.

Indépendamment de la définition de sec = ntlm ou de sec = ntlmv2 ou de sec = ntlmssp ou de l’une des autres options généralement proposées en tant que "solution" (c.-à-d. En définissant file_mode ou user ou gid).

Dans chaque la solution de nos installations a finalement été la même: réinitialisez le mot de passe de l'utilisateur samba et le montage fonctionne, quelles que soient les options de configuration!

Je ne sais pas ce qui se passe lorsque le mot de passe est "hérité/converti" à partir du compte Linux de l'utilisateur, mais il semble y avoir un problème important, indépendamment de la possibilité de parcourir (pas de monter) un partage Samba.

Je vais maintenant échanger cette réponse avec quelques articles similaires de AskUbuntu qui promeuvent les mêmes "réponses" qui, souvent, ne semblent pas aider ceux qui ont des problèmes.

Peut-être que cette approche vous aidera à relever le défi de la samba fstab. Je l'espère et bonne chance.

2
FBachofner
mount -t cifs -o ro,iocharset=utf8,sec=ntlm,username=everyone,password=null,vers=3.0 //file.biliops.com/Public-Share /mnt/cifs

Succès.

1
higkoo

J'ai récemment rencontré ce problème. Votre problème est que vous ne pouvez pas monter un sous-dossier d’un partage smb/cifs - vous ne pouvez monter que le partage lui-même (c’est-à-dire ne pas essayer de monter '// server/share/dir-1/dir-2/dir -3 ', montez à la place' // serveur/partage '). Essayer...

Sudo mount -t cifs //server01.mycompany.com/archive$/home/rawdata2 -o utilisateur = hari.nom, rw, logiciel, nosuid, uid = 1000, gid = 1000

... puis accédez au répertoire souhaité via "/ home/rawdata2/StructuralBiology/RAW-Data"

Si vous voulez vraiment que ce répertoire 'RAW-Data' soit disponible sous le nom '/ home/rawdata2', vous pouvez alors monter le partage dans un emplacement à l'écart et utiliser un lien symbolique comme celui-ci ...

Sudo mount -t cifs //server01.mycompany.com/archive$ /home/.hidden-mount -o user = hari.nom, rw, soft, nosuid, uid = 1000, gid = 1000

ln -s /home/.hidden-mount/StructuralBiology/RAW-Data/home/rawdata2

1
Nestor Custodio

Je sais que cela ne concerne pas exactement votre problème, mais je veux simplement ajouter une note aux personnes qui utilisent la méthode de montage KRB5 et qui voient:

mount error(13): Permission denied

Je rencontrais un problème dans le noyau 3.16 de Debian 8.10 dans lequel KRB5 + SMB1.0 était la seule combinaison qui fonctionnait.

Le montage avec vers = {2.0, 2.1, 3.0} a donné une autorisation refusée, mais cela fonctionnait sur d’autres hôtes Linux (plus récents).

La mise à niveau vers le noyau 4.10 a résolu ce problème. Espérons que cela aide quelqu'un là-bas!

0
skupeez