Comment monter automatiquement ses partages SAMBA - CIFS ?

Lors de la mise en place de mes clients SAMBA avec Linux (Mandriva/KDE4 et Gentoo/Fluxbox), j'ai rencontré des difficultés pour les monter automatiquement (cf. Installer les clients Samba). Sans parler du fait que l'on passait d'une commande smbmount devenue obsolète à une commande mount.cifs qui ne réagissait pas tout à fait de la même manière, il y a eu des problèmes et/ou difficultés de plusieurs ordres, les fonctionnels et les emm...dants :

1. Les montages doivent être fonction de l'utilisateur
2. La problématique de la commande mount
   
3. Les caractères accentués, encore et toujours
   
4. Les uid avec des prénoms composés ne sont pas reconnus
5. "E200: Les autocommandes *ReadPre ont rendu le fichier illisible"
   

• avant de lancer vos scripts, faites un set x (pour supprimer ce mode trace set --)
  

• ajouter --verbose avant -o

1 - Les montages doivent être fonction de l'utilisateur

En effet si plusieurs partages peuvent être communs à un groupe d'utilisateurs, l'espace personnel est ... personnel. Ce point ne prédispose pas à une solution générique de montages effectués à la séquence de démarrage de l'ordinateur (type fstab ou script lancé au démarrage comme on a pu le faire dans l'article "Comment activer et monter automatiquement des Volumes Logiques (LV) ?"). Et ce d'autant plus que cette méthode demande un séquençage particulier puisque vous devez effectuer vos montages après le lancement de votre connexion réseau, or les autres montages /boot notamment doivent se faire dès le début.

Le mieux est que le montage se fasse lors de l'ouverture de la session (graphique en générale) de l'utilisateur. Lorsqu'il y a plusieurs montages à faire, comme dans mon cas (3 communs et 1 personnel), le plus simple est de mettre les commandes de montage dans un script que pour ma part j'ai appelé avec beaucoup d'originalité my_smbmount. Comme souvent il faut défaire ce que l'on a fait, j'ai également créé un my_smbumount.

Je les ai placés assez logiquement sous /usr/local/bin/ et je les appelle avec 1 paramètre qui est le nom de l'utilisateur. Une ligne du script my_smbmount ressemble à cela (Attention non définitif) :

mount.cifs //<IP_serveur>/Archives /home/${1}/Serveur_Archives -o uid=${1},rw,credentials=/home/${1}/.smb_credentials

et une ligne du script my_smbumount ressemble à :

umount.cifs /home/${1}/Serveur_Archives

• Vous aurez compris que ${1} récupère le premier argument qui suit la commande my_smb(u)mount (ex : # my_smbmount freecrazy)
• Le script doit être exécutable (# chmod u+x my_smbmount)
• Et, c'est évident mais il vaut mieux le répéter les points de montage ont été créés (exemple $ mkdir ~/Serveur_Archives), ainsi que le fichier .smb_credentials qui doit être en droits très limités (600 voire 400) car il contient votre username et votre mot de passe sous la forme (attention pas d'espaces autour du '=', smbmount l'accepter pas mount.cifs) :
  

  username=<votre nom d'utilisateur>
  password=<votre mot_de passe>

Bon, d'accord on a un (même deux) script, qui fonctionne (testez le en le lançant en ligne de commande) mais comment fait-on pour qu'il démarre automatiquement à l'ouverture de la session de l'utilisateur ?

Comme souvent il y a plusieurs possibilités.

1.1 - Montage automatique à l'ouverture de la session graphique

Le terminal texte ? très peu pour vous. Lorsque vous travaillez sur votre ordinateur Linux, vous êtes toujours en session graphique, hé bien ce paragraphe est pour vous. J'y aborde les environnements KDE (testé), GNOME (testé), Fluxbox (testé).

Tous ces environnements (et je pense que les autres ont la même particularité) permettent de lancer des applications en même temps que le lancement de l'environnement graphique :

• sous KDE il suffit de mettre la commande de lancement (qui est aussi un script par exemple startsmb.sh oui je sais toujours cette originalité qui me caractérise) sous ~/.kde4/Autostart/ . (Pour les autres possibilités voir ce howto sur commentcamarche)
  
• sous GNOME il est plus simple d'utiliser la gestion de session : Système > Préférences > Session ou Applications au démarrage (cf. cehowto sur commentcamarche ). Un lanceur d'application (un petit script en <nom de l'appli>.desktop) se mettra  sous ~/.config/autostart. L'application à lancer est alors notre startsmb.sh.
  A noter : KDE utilise aussi ce qu'il y a sous ~/.config/autostart donc si vous travaillez sous ces 2 environnements il n'est pas utile d'utiliser ~/.kde/Autostart.
  
• sous Fluxbox l'appel de my_smbmount se fait en ajoutant une ligne dans ~/.fluxbox/startup
  

Sympa non ? La ligne de commande vous sera précisée au paragraphe suivant (2 - Lancer la commande mount en tant qu'utilisateur).
Nota :

• Les montages ne se font que lorsque la session graphique est lancée. Ben oui, c'est ce qu'on voulait non ?
• Je n'ai pas de solution pour le démontage. Sous KDE, fût un temps il existait pour cela le répertoire ~/.kde/Shutdown mais sous la version 4.3 ce répertoire n'existe plus. Suffit-il de le créer ? je ne sais pas, je n'ai pas testé. Pour Gnome je n'ai pas trouvé. Pour Fluxbox cela n'existe pas. Est-ce gênant ?, je pense que oui (mais je n'ai pas encore creusé), notamment lorsqu'on change d'utilisateur ou lorsqu'un même utilisateur change de session graphique (de KDE à Gnome par exemple).

1.2 - Montage automatique à l'ouverture de la session utilisateur

Certains ne se connectent qu'en mode terminal, sans ouvrir de session graphique, ou d'autres (comme moi) ouvrent d'abord une session en mode terminal puis lance l'environnement graphique avec startx (cela permet de débugger en cas de problème sur le serveur X), hé bien dans ces cas il y a aussi une solution. Cette solution est même plus générique que la précédente car elle doit être valable pour toutes distributions (désolé, mais je ne les ai pas toutes testées ;-) et elle est plus puissante puisqu'elle permet également le démontage.

Par défaut, sur toute distribution classique, chaque utilisateur se voit doté du shell Bash, et de ses fichiers associés .bash_profile (ou .bashrc) et .bash_logout. Ces 2 fichiers sont lus respectivement à l'ouverture et à la fermeture de la session utilisateur.

Donc il suffit d'y mettre la ligne d'appel de my_smbmout (ou de my_smbumount respectivement) et le tour est joué !.

• La problématique du démontage ne devrait plus exister, puisque lorsqu'on se déconnecte on quitte la session utilisateur. Mais au moins sous Mandriva, cela ne marche pas, si je me déconnecte et me reconnecte sous un utilisateur différent, les montages précédents sont encore présents (certes visibles que par root).
  

2 - La problématique de la commande mount

La commande mount proprement dite pose problème, car passée en ligne de commande cela marche très bien, mais lorsque cette commande figure au sein d'un script et bien ... cela n'est plus le cas. En fait mount doit être exécutée par le super-utilisateur root, et le chemin (path) de la commande doit être connu.

2.1 - Lancer la commande mount en tant qu'utilisateur

Une difficulté est que la commande mount doit être exécuté par le super utilisateur (root), donc notre script aussi, tout en étant lancé par l'utilisateur. En effet la fameuse commande de lancement évoquée précédemment se trouve dans des fichiers 'utilisateur'.

Le plus simple pour résoudre ce problème est d'utiliser la commande sudo qui donne des droits de super utilisateur pour la seule commande qui suit. On a ainsi une commande de lancement qui est de la forme :

sudo my_smbmount $USER

Un autre intérêt du sudo est que $USER contient bien le nom d'utilisateur (alors que lorsque vous lancez le script en tant que super utilisateur, la variable $USER contient root). Cela nous donne un commande très générique que l'on pourra copiée dans l'environnement de chaque utilisateur (même si c'est assez inutile ici puisque nous n'échapperons pas à un minimum de personnalisation comme la création des points de montage)

L'utilisation de sudo est pratique et préférable à la mise en place du setuid (chmod u+s my_smbmount), et ce d'autant plus que l'on peut spécifier quelle application est autorisée pour tel utilisateur (si par exemple vous êtes l'administrateur et vous ne voulez pas donner ce droit absolu à d'autres). Cela se fait dans le fichier /etc/sudoers.

Il est à noter que :

• sous Mandriva la commande avec sudo constitue la seule ligne de startsmb.sh que l'on met sous ~/.kde4/Autostart (ou que l'on appelle - cf. supra) ou la commande s'écrit à la fin de ~/.bash_profile
  
• sous Gentoo l'utilisation de cette commande se fait à l'intérieur de .bashrc (.bash_profile renvoie sur .bashrc) ou de .fluxbox/startup
  

2.2 - Le chemin (path) de la commande mount doit être connu

Selon l'endroit où vous avez mis votre script et selon votre configuration, il est possible que le système ne sache plus retrouver la commande mount. C'est encore plus vrai pour le script que le système ne connaît pas.

Cela se traduit par des exécutions différentes entre la commande lancée à la main et celle lancée dans un script. La résolution de ce point est simple, il suffit de donner le chemin complet de la commande comme /bin/mount.cifs ou quelque chose de similaire (faites un whereis mount.cifs pour connaître les différents chemins, vous pouvez en avoir plusieurs car il existe également des liens).

C'est pourquoi maintenant, dans un script, je mets systématiquement le chemin complet d'une commande. Cela m'évite des aléas de fonctionnement.

3 - Les caractères accentués encore et toujours

J'ai bien sûr eu droit encore et toujours à la problématique des caractères accentués : lorsque je passais ma commande "à la main" (# mount.cifs ...), soit le point de montage posait problème (ex Média), soit les dossiers des montages posaient problème (ex <point_de_montage>/Téléchargements) : hiéroglyphes à la place des caractères accentués et/ou fichiers non accessibles.
La solution est simple (1), il suffit d'ajouter l'option iocharset="utf8" (A noter que smbmount est sensé aussi accepté cette option mais, chez moi, cela n'a pas fonctionné, mais bon, smbmount n'est plus à utiliser)

1 - Solution simple, c'est vite dit. Car votre système doit être paramétré pour reconnaître l'UTF8 (mais en principe c'est le cas pour toute distribution récente francisée).

4 - Les uid avec des prénoms composés ne sont pas reconnus

Lorsque je me suis mis à écrire ces lignes, je ne me souvenais plus dans quel contexte j'avais rencontré ce problème et je n'ai pas réussi à le reproduire. Tout ce dont je me souviens est que lorsque je passais (en argument ?) un prénom composé comme marie-claire dans les options (uid=) et bien cela ne fonctionnait pas (interprétation du '-' comme l'annonce d'options ?) .

Je retrouvais un fonctionnement normal lorsque je mettais le prénom entre " " comme ceci uid="${USER}". Du coup j'ai adopté cette écriture.

5 - "E200: Les autocommandes *ReadPre ont rendu le fichier illisible"

Quel titre barbare ! Ce message énigmatique est apparu sous Gentoo. J'avais mon script sous /usr/local/bin et ma ligne de lancement sous .bashrc ou .fluxbox/startup peu importe. Normalement cela devait fonctionner, et à première vue cela en donnait l'impression puisque les montages s'effectuaient et je pouvais lire dossiers et fichiers.

Mais j'obtenais un fonctionnement curieux lorsque dans un dossier commun comme Serveur_Archives je créais un fichier avec l'explorateur de fichiers ROX-filer : lorsque j'essayais d'ouvrir avec l'éditeur de texte "vi" le fichier créé, j'obtenais "E200: Les autocommandes *ReadPre ont rendu le fichier illisible" ou pour les anglophones "E200: *ReadPre autocommands made the file unreadable". La création par une autre application comme OpenOffice aboutissait également à une erreur et une impossibilité d'écrire.

Cela m'a laissé perplexe quelque temps, et après moult essais d'options diverses comme nosetuids, setuids, file_mode, dir_mode, je me suis dit que cela devait venir des propriétés de l'utilisateur qui avait été créé avec uid=freecrazy et gid=freecrazy. Je remets tout cela en ordre (cf. gestion des utilisateurs), à savoir un uid=freecrazy et un gid=famille, et là tout fonctionne correctement à un détail près : la création d'un fichier sur un dossier commun est créé avec des droits rw.r..r donc avec impossibilité d'écrire puisque c'est en tant que gid=famille que l'on est sensé pouvoir écrire. Je n'ai pas réussi à trouver comment changer ce fonctionnement propre à ROX, le seul contournement est de modifier pour chaque fichiers ainsi créés les permissions avec ROX en mettant un g+w.

A noter que la création avec d'autres applications comme "vi" (vi ~/Serveur_Archives/test_new.txt) par exemple donne les bons droits (rw.rw....)

6 - Les scripts finaux

6.1 - /usr/local/bin/my_smbmount

Le script qui suit correspond à Gentoo-Fluxbox car sous Mandriva-KDE le chemin est /bin/mount.cifs3 et j'ai préféré mettre les points de montage sur le bureau (/home/${1}/Bureau/xxxx)

#! /usr/bin/env bash
/usr/bin/mount.cifs //<ip_serveur>/Archives /home/${1}/Serveur_Archives \
-o iocharset="utf8",uid="${1}",rw,credentials=/home/${1}/.smb_credentials 
/usr/bin/mount.cifs //<ip_serveur>/Famille /home/${1}/Serveur_Famille \
-o iocharset="utf8",uid="${1}",rw,credentials=/home/${1}/.smb_credentials
/usr/bin/mount.cifs //<ip_serveur>/Média /home/${1}/Serveur_Média \
-o iocharset="utf8",uid="${1}",rw,credentials=/home/${1}/.smb_credentials
/usr/bin/mount.cifs //<ip_serveur>/${1} /home/${1}/Serveur_${1} \
-o iocharset="utf8",uid="${1}",rw,credentials=/home/${1}/.smb_credentials

Bien sur le .smb_credentials doit être créé et contenir :

username=<nom d'utilisateur>
password=<mot de passe de l'utilisateur>

Ses droits seront ramenés à 400 soit lecture pour le seul utilisateur

6.2 - /usr/local/bin/my_smbumount

N'oubliez pas de mettre le chemin correspondant à votre distribution, ici c'est pour Gentoo-Fluxbox.

#! /usr/bin/env bash
/usr/bin/umount.cifs /home/${1}/Serveur_Archives
/usr/bin/umount.cifs /home/${1}/Serveur_Famille
/usr/bin/umount.cifs /home/${1}/Serveur_Média
/usr/bin/umount.cifs /home/${1}/Serveur_${1}

6.3 - La ligne de lancement du script de montage

Dans ~/.bash_profile (Mandriva), ~/.bashrc (Gentoo) ou ~/.fluxbox/startup ou dans ~/.kde4/Autostart/startsmb.sh (à créer et à rendre exécutable), on ajoute la ligne suivante :

sudo /usr/local/bin/my_smbmount $USER &

Nota : le & de fin de ligne, met la commande en arrière-plan (tâche de fond). Je ne vois pas l'intérêt mais le système est plus stable.

6.4 - La ligne de lancement du script de démontage

Pour finir il est bon de songer au démontage que l'on met dans ~/.bash_logout, en ajoutant la ligne :

sudo /usr/local/bin/my_smbumount $USER &

Bien sûr, à part les 2 scripts sous /usr/local/bin/ , toutes les autres modifications/créations sont à faire pour chaque utilisateur utilisant la même machine.