montage.cifs

user=arg

spécifie le nom d’utilisateur sous lequel se connecter. Si ce n’est pas donné, la variable d’environnement USER est utilisée. Cette option peut également prendre la forme « user%password » ou « workgroup /user » ou « workgroup /user%password » pour permettre que le mot de passe et le groupe de travail soient spécifiés dans le nom d’utilisateur.

password=arg

spécifie le mot de passe CIFS. Si cette option n’est pas donnée, l’environnement variablePASSWD est utilisé. Si le mot de passe n’est pas spécifié directement ou indirectement via un argument à mount, mount.les cifs inciteront un mot de passe, sauf si l’option invité est spécifiée.

Notez qu’un mot de passe qui contient le delimitercaracter (i.e. une virgule ‘, ‘) ne sera pas analysée correctement sur la ligne de commande. Cependant, le même mot de passe défini dans la variable d’environnement PASSWD ou via un fichier d’informations d’identification (voir ci-dessous) ou saisi à l’invite de mot de passe sera lu correctement.

credentials=filename

spécifie un fichier contenant un nom d’utilisateur et/ou un mot de passe. Le format du fichier est le suivant:

usernamevaluepasswordvalue

Il est préférable d’avoir des mots de passe en texte brut dans un fichier partagé, tels que /etc/fstab. Assurez-vous de protéger correctement le fichier anycredentials.

uid=arg

définit l’uid qui possédera tous les fichiers sur le montage filesystem.It peut être spécifié sous la forme d’un nom d’utilisateur ou d’un uid numérique.Pour les montages sur des serveurs qui prennent en charge les extensions Unix CIFS, comme un serveur Samba correctement configuré, le serveur fournit l’uid, le gid et le mode, ce paramètre ne doit donc pas être spécifié à moins que la numérotation uid et gid du serveur et du client ne diffère. Si le serveur et le client sont dans le même domaine (par ex. en exécutant winbind ou nss_ldap) et que le serveur prend en charge les extensions Unix, l’uid et le gid peuvent être récupérés à partir du serveur (et l’uid et le gid n’auraient pas besoin d’être spécifiés sur le montage. Pour les serveurs qui ne prennent pas en charge les extensions Unix CIFS, l’uid (et le gid) par défaut renvoyés lors de la recherche des fichiers existants sera l’uid (gid) de la personne qui a exécuté le montage (root, sauf lors du montage.cifs est configuré setuid pour les montages utilisateur) sauf si l’option de montage « uid= » (gid) est spécifiée. Pour l’uid (gid) des fichiers et répertoires nouvellement créés, c’est-à-dire des fichiers créés depuis le dernier montage du partage serveur, l’uid attendu (gid) est mis en cache tant que l’inode reste en mémoire sur le client. Notez également que les contrôles d’autorisation (contrôles d’autorisation) sur les accès à un fichier se produisent sur le serveur, mais il existe des cas dans lesquels un administrateur peut également vouloir restreindre les accès au client. Pour les serveurs qui ne signalent pas de propriétaire uid/gid (comme Windows), les autorisations peuvent également être vérifiées sur le client, et une forme brute de vérification des autorisations côté client peut être activée en spécifiant file_mode et dir_mode sur le client. Notez que la monture.l’assistant cifs doit être à la version 1.10 ou supérieure pour prendre en charge la spécification de l’uid (ou du gid) sous une forme non numérique.

gid=arg

définit le gid qui possédera tous les fichiers du système de fichiers monté. Il peut être spécifié sous la forme d’un nom de groupe ou d’un gid numérique. Pour d’autres considérations, voir la description de l’uid ci-dessus.

port=arg

définit le numéro de port sur le serveur pour tenter de contacter pour négocier le support des fichiers. Si le serveur CIFS n’écoute pas sur ce port ou s’il n’est pas spécifié, les ports par défaut seront essayés, c’est-à-dire que le port 445 est essayé et si aucune réponse, le port 139 est essayé.

servern=arg

Spécifiez le nom netbios du serveur (nom RFC1001) à utiliser lors de la tentative de configuration d’une session sur le serveur. Bien que rarement nécessaire pour le montage sur des serveurs plus récents, cette option est nécessaire pour le montage sur certains serveurs plus anciens (tels que OS / 2 ou Windows 98 et Windows ME) car lors de la connexion sur le port 139, ils ne prennent pas en charge un nom de serveur par défaut. Un nom de serveur peut contenir jusqu’à 15 caractères et est généralement en majuscules.

netbiosname=arg

Lors du montage sur des serveurs via le port 139, spécifie le nom source RFC1001 à utiliser pour représenter le nom de la machine client netbios lors de l’initialisation de la session RFC1001 netbios.

file_mode=arg

Si le serveur ne prend pas en charge les extensions Unix CIFS, cela remplace le mode de fichier par défaut.

dir_mode=arg

Si le serveur ne prend pas en charge les extensions Unix CIFS, cela remplace le mode par défaut pour les répertoires.

ip=arg

définit l’adresse IP de destination. Cette option est définie automatiquement si la partie nom du serveur du nom UNC demandé peut être résolue, ce qui nécessite rarement d’être spécifié par l’utilisateur.

domain=arg

définit le domaine (groupe de travail) de l’utilisateur

invité

ne demande pas de mot de passe

iocharset

Jeu de caractères utilisé pour convertir les noms de chemin locaux vers et à partir deunicode. Unicode est utilisé par défaut pour les chemins d’accès réseau si le serveur le prend en charge. Si iocharset n’est pas spécifié, le paramètre nls_default spécifié pendant la construction du noyau client local sera utilisé.Si le serveur ne prend pas en charge Unicode, ce paramètre n’est pas utilisé.

ro

montage en lecture seule

rw

montage en lecture-écriture

setuid

Si les extensions Unix CIFS sont négociées avec le serveur, le client tentera de définir l’uid et le gid effectifs du processus local sur les fichiers, répertoires et périphériques nouvellement créés (create, mkdir, mknod). Si les extensions Unix CIFS ne sont pas négociées, pour les fichiers et répertoires nouvellement créés au lieu d’utiliser l’uid et le gid par défaut spécifiés sur le montage, mettez en cache localement l’uid et le gid du nouveau fichier, ce qui signifie que l’uid du fichier peut changer lorsque l’inode est rechargé (ou que l’utilisateur remonte le partage).

nosetuids

Le client ne tentera pas de définir l’uid et le gid sur les fichiers, répertoires et périphériques nouvellement créés (create, mkdir, mknod), ce qui obligera le serveur à définir l’uid et le gid par défaut (généralement l’uid serveur de l’utilisateur qui a monté le partage). Laisser le serveur (plutôt que le client) définir l’uid et le gid est la valeur par défaut.Si les extensions Unix CIFS ne sont pas négociées, l’uid et le gid pour les nouveaux fichiers apparaîtront être l’uid (gid) du monteur ou le paramètre uid (gid) spécifié sur le montage.

perm

Le client effectue des vérifications d’autorisation (vérification vfs_permission de l’uid et du gid du fichier par rapport au mode et au fonctionnement souhaité), Notez que cela s’ajoute à la vérification ACL normale sur la machine cible effectuée par le logiciel serveur. La vérification des autorisations du client est activée par défaut.

le client noperm

ne vérifie pas les autorisations. Cela peut exposer les fichiers de ce montage à l’accès d’autres utilisateurs sur le système client local. Il n’est généralement nécessaire que lorsque le serveur prend en charge les extensions Unix CIFS, mais que les UID/GID sur le système client et serveur ne correspondent pas assez étroitement pour permettre l’accès à l’utilisateur effectuant le montage. Notez que cela n’affecte pas la vérification ACL normale sur la machine cible effectuée par le logiciel serveur (de l’ACL serveur par rapport au nom d’utilisateur fourni au moment du montage).

directio

Ne faites pas de mise en cache des données d’inode sur les fichiers ouverts sur ce montage. Cela empêche le mmaping des fichiers sur ce support. Dans certains cas, avec des réseaux rapides et peu ou pas d’avantages de mise en cache sur le client (par ex. lorsque l’application effectue de grandes lectures séquentielles plus grandes que la taille de la page sans relire les mêmes données), cela peut fournir de meilleures performances que le comportement par défaut qui met en cache les lectures (readahead) et les écritures (writebehind) via le client Linux local pagecache si oplock (jeton de mise en cache) est accordé et maintenu. Notez que direct permet d’envoyer des opérations d’écriture supérieures à la taille de la page au serveur. Sur certains noyaux, cela nécessite les cifs.le module ko doit être construit avec l’option de configuration CIFS_EXPERIMENTAL.

mapchars

Traduisez six des sept caractères réservés (pas de barre oblique inverse, mais incluant les deux points, le point d’interrogation, le tuyau, l’astérik, les caractères supérieurs et inférieurs à) dans la plage de remap (au-dessus de 0xF000), ce qui permet également au client CIFS de reconnaître les fichiers créés avec de tels caractères par l’émulation POSIX de Windows. Cela peut également être utile lors du montage sur la plupart des versions de Samba (ce qui interdit également de créer et d’ouvrir des fichiers dont les noms contiennent l’un de ces sept caractères). Cela n’a aucun effet si le serveur ne prend pas en charge Unicode sur le fil.

nomapchars

Ne traduit aucun de ces sept caractères (par défaut)

intr

actuellement non implémenté

nointr

(par défaut) actuellement non implémenté

hard

Le programme accédant à un fichier sur le système de fichiers monté cifs se bloque lorsque le serveur se bloque.

soft

(par défaut) Le programme accédant à un fichier sur le système de fichiers monté sur cifs ne se bloque pas lorsque le serveur se bloque et renvoie les erreurs à l’application utilisateur.

noacl

N’autorisez pas les opérations ACL POSIX même si le serveur les prend en charge.

Le client CIFS peut obtenir et définir des ACL POSIX (getfacl, setfacl) sur Samba serversversion 3.10 et versions ultérieures. La définition d’ACL POSIX nécessite l’activation à la fois de XATTR et de la prise en charge POSIX dans les options de configuration CIFS lors de la construction du module cif. La prise en charge ACL POSIX peut être désactivée sur une base par montage en spécifiant « noacl » sur le montage.

nocase

Demande une correspondance de nom de chemin insensible à la casse (la casse est la valeur par défaut si le serveur la prend en charge).

sec=

Mode de sécurité. Les valeurs autorisées sont:

est en cours de développement et pour être disponible dans le module noyau cifs 1.40 et versions ultérieures]

nobrl

N’envoyez pas de demandes de verrouillage de plage d’octets au serveur. Ceci est nécessaire pour certaines applications qui rompent avec les verrous de plage d’octets obligatoires de style cifs (et la plupart des serveurs cifs ne prennent pas encore en charge la demande de verrous de plage d’octets consultatifs).

sfu

Lorsque les extensions CIFS Unix ne sont pas négociées, essayez de créer des fichiers de périphériques et des FIFO dans un format compatible avec Services for Unix (SFU). De plus, récupérez les bits 10-12 du mode via l’attribut étendu SETFILEBITS (comme le fait SFU). À l’avenir, les 9 bits inférieurs du mode mode seront également émulés à l’aide de requêtes du descripteur de sécurité (ACL). [NB : nécessite la version 1.39 ou ultérieure du VFS CIFS. Reconnaître les liens symboliques et pouvoir créer des liens symboliques dans un formulaire interopérable SFU nécessite la version 1.40 ou ultérieure du module noyau CIFS VFS.

serverino

Utilise des numéros d’inode (identifiants de fichiers persistants uniques) renvoyés par le serveur au lieu de générer automatiquement des numéros d’inode temporaires sur le client. Bien que les numéros d’inode du serveur facilitent la détection des fichiers liés en dur (car ils auront les mêmes numéros d’inode) et que les numéros d’inode puissent être persistants (ce qui est utile pour certains logiciels), le serveur ne garantit pas que les numéros d’inode sont uniques si plusieurs montages côté serveur sont exportés sous un seul partage (car les numéros d’inode sur les serveurs peuvent ne pas être uniques si plusieurs systèmes de fichiers sont montés sous le même répertoire de niveau supérieur partagé). Notez que tous les serveurs ne prennent pas en charge les numéros d’inode de serveur renvoyés, bien que ceux qui prennent en charge les extensions Unix CIFS, et les serveurs Windows 2000 et plus récents le prennent généralement en charge (bien que pas nécessairement sur tous les systèmes de fichiers de serveur local). Le paramètre n’a aucun effet si le serveur ne prend pas en charge le retour des numéros d’inode ou équivalents.

le client noserverino

génère des numéros d’inode (plutôt que d’utiliser celui du serveur) par défaut.

nouser_xattr

(par défaut) N’autorise pas getfattr/setfattr à obtenir/définir des xattrs, même si le serveur le supporterait autrement.

rsize=arg

taille de lecture réseau par défaut (généralement 16K). Le client ne peut actuellement pas utiliser rsize plus grand que CIFSMaxBufSize. CIFSMaxBufSize est par défaut à 16K et peut être modifié (de 8K à la taille maximale de kmalloc autorisée par votre noyau) au moment de l’installation du module pour les cifs.ko. La définition de CIFSMaxBufSize à une très grande valeur entraînera une utilisation accrue de mémoire par les cifs et peut réduire les performances dans certains cas. Pour utiliser rsize supérieur à 127 Ko (le maximum du protocole cifs d’origine), le serveur doit également prendre en charge un nouvel indicateur de capacité Unix (pour une lecture très importante), ce que font certains serveurs plus récents (par exemple Samba 3.0.26 ou version ultérieure). rsize peut être défini d’un minimum de 2048 à un maximum de 130048 (127K ou CIFSMaxBufSize, selon la taille la plus petite)

wsize=arg

taille d’écriture réseau par défaut (57344 par défaut) la taille maximale actuellement autorisée par CIFS est de 57344 (quatorze pages de 4096 octets)

verbdétaillée

Imprimer des informations de débogage supplémentaires pour la monture. Notez que ce paramètre doit être spécifié avant le -o. Par exemple :

mount-t cifs//server/share/mntverbverbose-o user=username