La mejor práctica para montar una partición de Windows


13

Estoy ejecutando un arranque dual de Windows y Debian en mi computadora portátil. Uso Linux principalmente, pero de vez en cuando necesito acceder a mis archivos en mi partición de Windows. Mi partición de Windows se monta de la siguiente manera al inicio.

>cat /etc/fstab |grep Win7
LABEL=Windows7_OS /mnt/Win7 auto nosuid,nodev,nofail,x-gvfs-show 0 0

Básicamente, cada archivo en la partición de Windows es propiedad de root: root y tiene un permiso 777. Luego, cada vez que mv un archivo a mi partición de trabajo (Linux), tengo un archivo 777 debajo de mi partición, propiedad mía (mientras que cp en la terminal dará un archivo 755 pero si se hace a través de gnome guardará el archivo con un permiso 777) .

¿Es esta la mejor práctica para montar una partición? ¿O debería montarlo de modo que, en lugar de root, sea el propietario de todos los archivos / directorios y de alguna manera pueda configurar todos los directorios en 755 y archivos en 644 cuando el montaje ocurra en el arranque? Si es así, ¿cómo se puede hacer esto?


2
tidbit menor (uooc ...):grep Win7 /etc/fstab
Olivier Dulac

Respuestas:


17

Puede usar fmasky dmaskmontar opciones * para cambiar la asignación de permisos en un sistema de archivos ntfs.

Para que aparezcan los archivos rw-r--r--(644) y los directorios rwxr-xr-x(755) fmask=0133,dmask=0022. Esto se puede combinar con uid=y gid=opciones para seleccionar el propietario del archivo y el grupo Si necesita acceso de escritura para el usuario.

* fmasky dmaskparece funcionar también para el controlador del núcleo (solo lectura), incluso si no están documentados en la página de manual de montaje . Son opciones documentadas para ntfs-3g.


Mi umask predeterminado es 0022 ya. Pero cuando mV un archivo utilizando el terminal de Win7 a mi casa el archivo sigue siendo 777.
albertma789

2
El fmask y el dmask en la respuesta son opciones de montaje . Cuando los cambie en fstab y vuelva a montar el sistema de archivos, los archivos / directorios en su sistema de archivos de Windows aparecerán con permisos 644/755 en lugar de 777/777.
sebasth el

55
LABEL=Windows7_OS /media/Win7 auto nosuid,nodev,nofail,x-gvfs-show,x-gvfs-name=Windows,uid=1000,gid=1000,fmask=0133,dmask=0022 0 0Funciona de maravilla. ¡Exactamente lo que necesitaba!
albertma789

¿Es posible configurar dichos valores predeterminados para sistemas de archivos específicos (FAT32 / NTFS) en lugar de unidades específicas? Sería bueno tener esto disponible cuando use unidades flash y otros medios extraíbles.
JAB


7

En primer lugar, no es así como debe usar / mnt. Eso es para realizar tareas administrativas en un sistema de archivos temporalmente, no todos los arranques del sistema.

Debido a que la partición de Windows no forma parte del funcionamiento del sistema Linux, tiene sentido montarla en / media. También puede considerar montarlo en root / as / Windows para evitar confusiones sobre / media para medios extraíbles.

En cuanto a los permisos, usaría un grupo llamado windows

groupadd -g 1001 Windows

y dele los permisos que desee con opciones como:

gid=1001,umask=022

Si desea usar cp y mantener permisos entre sistemas de archivos separados, use cp con el indicador -p o -a.


Mi umask predeterminado es 0022 ya. Pero cuando mv un archivo usando el terminal de Win7 a mi casa, el archivo sigue siendo 777. ¡Montar en / media es una gran sugerencia!
albertma789

Al copiar archivos entre sistemas de archivos, se utilizan los permisos predeterminados para ese sistema de archivos a menos que los conserve. Consulte mi respuesta actualizada.
jdwolf

Si bien estoy de acuerdo, /mntno es óptimo para el punto de montaje, /mediaes para medios extraíbles (por ejemplo, DVD y unidades USB). No estoy seguro de que haya una buena respuesta donde se supone que sucederá el montaje: unix.stackexchange.com/questions/29134/…
StrongBad

@StrongBad El estándar de jerarquía del sistema de archivos no es tan estándar, especialmente en los directorios desde los antiguos Unix. Por ejemplo, el FHS 2.3 no refleja las prácticas actuales de / ejecución. Mire el FHS 3.0 refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s11.html que además indica que no debe usar / mnt para esto, pero su racionalidad es mucho más clara que "técnicamente Windows no es un medio extraíble". También vale la pena señalar que no hay nada de malo en montar su propio directorio en / root.
jdwolf

4

El uso de las opciones de montaje uid, gid, fmasky dmaskpuede hacer que todo el sistema de archivos NTFS puede acceder a su cuenta de usuario y / o un grupo. Pero eso es todo o nada: en lo que respecta al sistema de archivos NTFS, es como correr como Administrador completo todo el tiempo en Windows, o como hacer todo como root en Linux. El ntfs-3gcontrolador del sistema de archivos NTFS puede hacerlo mejor que eso.

Si está usando ntfs-3g, puede usar el ntfsusermapcomando para crear un archivo de mapeo de usuario para sus sistemas de archivos NTFS. El comando lo ayudará a identificar los nombres de usuario de Windows y sus correspondientes SID de Windows y asociarlos a las identificaciones de usuario y grupo de Linux.

De esta forma, puede asociar el SID de su cuenta de usuario de Windows a su UID de Linux. De esa manera, una vez que monte el sistema de archivos NTFS con el archivo de mapeo de usuario en su lugar <NTFS filesystem root>/.NTFS-3G/UserMapping, puede usar su cuenta de usuario de Linux normal para acceder al sistema de archivos NTFS exactamente como su cuenta de usuario de Windows podría acceder. Para las cosas que necesitaría permisos de administrador en Windows, aún necesitará root en Linux.

De esta manera, obtendrá un acceso conveniente a sus archivos en la partición de Windows, pero aún así está protegido de desordenar su \Windowsdirectorio mediante un comando mal escrito, a menos que esté ejecutando como root.

También es posible que desee utilizar la windows_namesopción de montaje en las particiones NTFS para evitar que cree accidentalmente archivos con nombres a los que Windows no puede acceder.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.