Monte.cifs

user = arg

especifica el nombre de usuario con el que conectarse. Si no se indica esto, se utiliza la variable de entorno USER. Esta opción también puede tomar el formulario «contraseña de usuario%» o «grupo de trabajo/usuario» o»contraseña de grupo de trabajo/usuario%» para permitir que la contraseña y el grupo de trabajo se especifiquen como parte del nombre de usuario.

password =arg

especifica la contraseña CIFS. Si no se da esta opción, se utiliza el entorno variablePASSWD. Si la contraseña no se especifica directa o indirectamente a través de un argumento para mount, mount.los cifs solicitarán una contraseña, a menos que se especifique la opción de invitado.

Tenga en cuenta que una contraseña que contiene el carácter delimitador (i. e. una coma ‘,’) no se analizará correctamente en la línea de comandos. Sin embargo, la misma contraseña definida en la variable de entorno PASSWD o a través de un archivo de credenciales (ver abajo) o introducida en la solicitud de contraseña se leerá correctamente.

credentials=filename

especifica un archivo que contiene un nombre de usuario y / o contraseña. El formato del archivo es:

usernamevaluepasswordvalue

Esto es preferible a tener contraseñas en texto plano en un archivo compartido, como /etc/fstab. Asegúrese de proteger correctamente cualquier archivo de credentials.

uid=arg

establece el uid que poseerá todos los archivos montados filesystem.It se puede especificar como un nombre de usuario o un uid numérico.Para montajes en servidores que admiten las extensiones de Unix CIFS, como un servidor Samba correctamente configurado, el servidor proporciona el uid, gid y mode, por lo que este parámetro no debe especificarse a menos que la numeración de uid y gid del servidor y del cliente sea diferente. Si el servidor y el cliente están en el mismo dominio (p. ej. ejecutar winbind o nss_ldap) y el servidor admite las extensiones Unix, entonces el uid y el gid se pueden recuperar del servidor (y el uid y el gid no tendrían que especificarse en el montaje. Para los servidores que no soportan las extensiones de Unix CIFS, el uid (y el gid) por defecto que se devuelven al buscar archivos existentes será el uid (gid) de la persona que ejecutó el montaje (root, excepto cuando se monta.cifs está configurado setuid para montajes de usuario) a menos que se especifique la opción de montaje» uid= » (gid). Para el uid (gid) de los archivos y directorios recién creados, es decir, los archivos creados desde el último montaje del recurso compartido de servidor, el uid (gid) esperado se almacena en caché mientras el inodo permanezca en memoria en el cliente. También tenga en cuenta que las comprobaciones de permisos (comprobaciones de autorización) en los accesos a un archivo se producen en el servidor, pero hay casos en los que un administrador puede querer restringir en el cliente también. Para aquellos servidores que no informan de un propietario de uid/gid (como Windows), los permisos también se pueden verificar en el cliente, y se puede habilitar una forma cruda de comprobación de permisos del lado del cliente especificando file_mode y dir_mode en el cliente. Tenga en cuenta que la montura.cifs helper debe estar en la versión 1.10 o superior para poder especificar el uid (o gid) en forma no numérica.

gid=arg

establece el gid que poseerá todos los archivos del sistema de archivos montado. Se puede especificar como un nombre de grupo o un gid numérico. Para otras consideraciones, consulte la descripción de uid anterior.

port=arg

establece el número de puerto en el servidor para intentar contactar con el soporte de negotiateCIFS. Si el servidor CIFS no está escuchando en este puerto si no está especificado, se probarán los puertos predeterminados, es decir, se probará el puerto 445 y si no hay respuesta, se probará el puerto 139.

servern =arg

Especifique el nombre netbios del servidor (nombre RFC1001) que se utilizará al intentar configurar una sesión en el servidor. Aunque es muy necesario para el montaje en servidores más nuevos, esta opción es necesaria para el montaje en algunos servidores más antiguos (como OS/2 o Windows 98 y Windows ME), ya que al conectarse al puerto 139, a diferencia de la mayoría de los servidores más nuevos, no admiten un nombre de servidor predeterminado. El nombre de un servidor puede tener hasta 15 caracteres de longitud y suele estar en mayúsculas.

netbiosname =arg

Al montar en servidores a través del puerto 139, especifica el nombre de origen RFC1001 que se utilizará para representar el nombre de máquina netbios del cliente al inicializar la sesión netbios RFC1001.

file_mode=arg

Si el servidor no admite las extensiones de Unix CIFS, esto supera el modo de archivo predeterminado.

dir_mode =arg

Si el servidor no es compatible con las extensiones de Unix CIFS, esto supera el modo predeterminado para los directorios.

ip=arg

establece la dirección IP de destino. Esta opción se establece automáticamente si la parte de nombre de servidor del nombre UNC solicitado se puede resolver, por lo que rara vez necesita ser especificada por el usuario.

domain =arg

establece el dominio (grupo de trabajo) del usuario

invitado

no solicita una contraseña

conjunto de caracteres iocharset

que se usa para convertir nombres de ruta locales a y de código remoto. Unicode se utiliza de forma predeterminada para los nombres de ruta de red si el servidor lo admite. Si iocharset no está especificado, se utilizará el nls_default specificeddurante la compilación del núcleo del cliente local.Si el servidor no admite Unicode, este parámetro no se utiliza.

ro

montar de solo lectura

rw

montar de lectura y escritura

setuids

Si las extensiones de Unix CIFS se negocian con el servidor, el cliente intentará establecer el uid y el gid efectivos del proceso local en archivos, directorios y dispositivos recién creados (create, mkdir, mknod). Si las extensiones de Unix CIFS no se negocian, para los archivos y directorios recién creados en lugar de usar el uid y el gid predeterminados especificados en el montaje, almacene en caché localmente el uid y el gid del nuevo archivo, lo que significa que el uid del archivo puede cambiar cuando se recarga el inode (o el usuario vuelve a montar el recurso compartido).

nosetuids

El cliente no intentará establecer el uid y el gid en los archivos, directorios y dispositivos recién creados (create, mkdir, mknod), lo que resultará en que el servidor establezca el uid y el gid en el valor predeterminado (generalmente el uid del servidor del usuario que montó el recurso compartido). Dejar que el servidor (en lugar del cliente) establezca el uid y el gid es el valor predeterminado.Si las extensiones de Unix CIFS no se negocian, el uid y el gid para archivos nuevos parecerán ser el uid (gid) del montador o el parámetro uid (gid) especificado en el montaje.

perm

El cliente realiza comprobaciones de permisos (comprobación vfs_permission de uid y gid del archivo contra el modo y la operación deseada), tenga en cuenta que esto es adicional a la comprobación ACL normal en la máquina de destino realizada por el software del servidor. La comprobación de permisos del cliente está habilitada de forma predeterminada.

el cliente noperm

no realiza comprobaciones de permisos. Esto puede exponer los archivos de esta montura al acceso de otros usuarios en el sistema cliente local. Por lo general, solo se necesita cuando el servidor admite las extensiones de Unix CIFS, pero los UIDs/GIDs en el sistema cliente y servidor no coinciden lo suficiente como para permitir el acceso del usuario que realiza el montaje. Tenga en cuenta que esto no afecta a la comprobación normal de ACL en la máquina de destino realizada por el software del servidor (de la ACL del servidor contra el nombre de usuario proporcionado en el momento del montaje).

directio

no inodo almacenamiento en caché de datos en archivos abiertos en este monte. Esto impide la creación de archivos mm en esta montura. En algunos casos, con redes rápidas y pocos o ningún beneficio de almacenamiento en caché para el cliente (p. ej. cuando la aplicación está haciendo grandes lecturas secuenciales mayores que el tamaño de la página sin volver a leer los mismos datos), esto puede proporcionar un mejor rendimiento que el comportamiento predeterminado que almacena en caché las lecturas (readahead) y las escrituras (writebehind) a través de la pagecache del cliente Linux local si se concede y se retiene oplock (token de almacenamiento en caché). Tenga en cuenta que direct permite enviar al servidor operaciones de escritura de mayor tamaño que la página. En algunos núcleos esto requiere los cifs.módulo ko que se construye con la opción de configuración CIFS_EXPERIMENTAL.

mapchars

Traducen seis de los siete caracteres reservados (no barra invertida, sino que incluyen los dos puntos, el signo de interrogación, la tubería, el asterisco, los caracteres mayores y menores que) al rango de reasignación (por encima de 0xF000), lo que también permite al cliente CIFS reconocer los archivos creados con dichos caracteres mediante la emulación POSIX de Windows. Esto también puede ser útil cuando se monta en la mayoría de las versiones de Samba (que también prohíbe crear y abrir archivos cuyos nombres contengan cualquiera de estos siete caracteres). Esto no tiene efecto si el servidor no admite Unicode en el cable.

nomapchars

No traduce ninguno de estos siete caracteres (predeterminado)

intr

actualmente sin implementar

nointr

(predeterminado) actualmente sin implementar

hard

El programa que accede a un archivo en el sistema de archivos montado cifs se colgará cuando el servidor se bloquee.

soft

(predeterminado) El programa que accede a un archivo en el sistema de archivos montado cifs no se colgará cuando el servidor se bloquee y devolverá errores a la aplicación de usuario.

noacl

No permite operaciones POSIX ACL aunque el servidor las admita.

El cliente CIFS puede obtener y establecer ACL POSIX (getfacl, setfacl) a Samba serversversion 3.10 y versiones posteriores. La configuración de ACL POSIX requiere habilitar el soporte XATTR y luego POSIX en las opciones de configuración de CIFS al compilar el módulo cifsm. El soporte de ACL POSIX se puede desactivar en un básico por montaje especificando»noacl» en el montaje.

no hay mayúsculas y minúsculas en la solicitud que coincida con el nombre de ruta que no distingue entre mayúsculas y minúsculas (distingue entre mayúsculas y minúsculas es el valor predeterminado si el servidor lo admite). sec =

Modo de seguridad. Los valores permitidos son:

está en desarrollo y se espera que para estar disponible en el módulo de núcleo cifs 1.40 y posteriores]

nobrl

No envíe solicitudes de bloqueo de rango de bytes al servidor. Esto es necesario para ciertas aplicaciones que rompen con bloqueos de rango de bytes obligatorios de estilo cifs (y la mayoría de los servidores cifs aún no admiten bloqueos de rango de bytes de asesoramiento para solicitudes).

sfu

Cuando las extensiones de Unix CIFS no se negocian, intente crear archivos de dispositivo y fifos en un formato compatible con Servicios para Unix (SFU). Además, recupere los bits 10-12 del modo a través del atributo extendido SETFILEBITS (como lo hace SFU). En el futuro, los 9 bits inferiores del modo mode también se emularán mediante consultas del descriptor de seguridad (ACL). [NB: requiere la versión 1.39 o posterior de CIFS VFS. Para reconocer enlaces simbólicos y ser capaz de crear enlaces simbólicos en un formulario interoperable SFU se requiere la versión 1.40 o posterior del módulo del núcleo CIFS VFS.

serverino

Utilice números de inodo (identificadores de archivo persistentes únicos)devueltos por el servidor en lugar de generar automáticamente números de inodo temporales en el cliente. Aunque los números de inodo del servidor facilitan la detección de archivos enlazados (ya que tendrán los mismos números de inodo) y los números de inodo pueden ser persistentes (lo que es útil para algunos softwares), el servidor no garantiza que los números de inodo sean únicos si se exportan varios montajes del lado del servidor bajo un solo recurso compartido (ya que los números de inodo en los servidores pueden no ser únicos si se montan varios sistemas de archivos bajo el mismo directorio compartido de nivel superior). Tenga en cuenta que no todos los servidores admiten la devolución de números de código de servidor, aunque los que admiten las extensiones de Unix CIFS, y los servidores Windows 2000 y posteriores normalmente admiten esto (aunque no necesariamente en todos los sistemas de archivos de servidor local). El parámetro no tiene efecto si el servidor carece de soporte para devolver números de inodo o equivalentes.

el cliente noserverino

genera números de inodo (en lugar de usar el real del servidor) de forma predeterminada.

nouser_xattr

(predeterminado) No permite que getfattr/setfattr obtenga/establezca xattrs, incluso si el servidor lo admitiría de otra manera.

rsize=arg

tamaño de lectura de red predeterminado (generalmente 16K). Actualmente, el cliente no puede usar rsize mayor que CIFSMaxBufSize. CIFSMaxBufSize tiene un valor predeterminado de 16K y se puede cambiar (de 8K al tamaño máximo de kmalloc permitido por su núcleo) en el momento de la instalación del módulo para cifs.ko. Establecer CIFSMaxBufSize a un valor muy grande hará que los cifs usen más memoria y puede reducir el rendimiento en algunos casos. Para usar un tamaño de r superior a 127K (el máximo del protocolo cifs original) también se requiere que el servidor soporte un nuevo indicador de capacidad Unix (para una lectura muy grande) que hacen algunos servidores más nuevos (por ejemplo, Samba 3.0.26 o posterior). rsize se puede configurar de un mínimo de 2048 a un máximo de 130048 (127K o CIFSMaxBufSize, el que sea más pequeño)

wsize=arg

tamaño de escritura de red predeterminado (57344 predeterminado) el tamaño máximo permitido actualmente por CIFS es de 57344 (catorce páginas de 4096 bytes)

Print detallado

Imprimir información de depuración adicional para la montura. Tenga en cuenta que este parámetro debe especificarse antes de-o. Por ejemplo:

mount-t cifs //server/share /mnt user verbose-o user=username