A raíz del post de Carpetas inmutables en QTS de Yeraycito y tras comentarlo en el grupo de Telegram estuve dándole vueltas a realizarlo mediante una aplicación en nuestra app center.
Y aquí estamos, pero como es algo delicado hay que tener unos requisitos previos sencillos y ciertas cautelas para usarlo (son cosas sencillas pero hay que saberlas).
hemos de tener un usuario administrador sudoer para que pueda ejecutar comandos con un sudo antepuesto a otros comandos sin una petición de clave. Se explica en este otro post
debemos saber la ruta completa de las carpetas a dejar en modo sólo lectura. Evidentemente, nos interesa que sean o estén dentro de una carpeta ya compartida. Si no se hace así las carpetas serían bloqueadas igualmente pero no podrían ser leídas por otros equipos.
Funcionamiento del qpkg
Al instalarlo, se ejecutará por primera vez y creará un archivo llamado "worm.cfg" en la carpeta compartida "Public".
Este archivo es editable y veremos que su contenido literalmente es "vacio"
Lo que debemos hacer es escribir por línea una o tantas rutas como queramos bloquear. Es muy importante que la última sea sin contenido.
Por ejemplo podría ser algo así
donde indicamos que va a ser inmutable la carpeta "Pruebas" y todo su contenido. Esta carpeta está ubicada en la compartida "Public".
Pero podríamos haber indicado otra compartida con otro nombre.
En este segundo ejemplo
además de la del ejemplo anterior, también hacemos inmutable a otra compartida de nombre "Carpetacompartida1"
En el tercer ejemplo
hacemos inmutables a las carpetas "Pruebas", "otra1" y "otra2" que están contenidas dentro de la carpeta compartida "Public"
Si reiniciamos el qpkg (detenerlo e iniciarlo) veremos que las carpetas de la configuración han quedado en modo lectura para todos, incluso para el usuario admin si lo reactivásemos.
Para hacer cambios de contenido en la carpeta o carpetas hemos de detener el qpkg desde el app center.
Para bloquear de nuevo el contenido, lo iniciamos nuevamente y lista de las carpetas del archivo "worm.cfg" quedarán bloqueadas.
Se ha previsto que en aquellos casos donde el usuario "admin" no está desactivado, el qpkg lo respeta y no lo desactiva tras la ejecución del qpkg.
En los siguientes enlaces dejo los qpkg ubicados en MEGA para los distintos tipos de nas.
Este post ha surgido como necesidad de tener un usuario sudoer en QTS.
Con las últimas versiones de QTS, se aconseja tener desactivado al usuario "admin" y tener otro usuario de nombre distinto en el grupo de administradores.
El motivo de tener querer hacer a un usuario administrador del grupo sudoers es que podamos ejecutar comandos con "sudo" y no se pida la introducción de la clave de forma manual.
En un linux normal con un "visudo" podemos editar y agregar al usuario que nos interese. Pero en QTS las cosas no son así.
Investigando un poco en la estructura de carpetas de la nas, vemos que hay un archivos llamado "sudoers" en la ruta /usr/etc/"
Si lo editamos y vamos a su última línea vemos que hay un "@includedir /usr/etc/sudoers.d"
Es decir que si creamos esa carpeta "sudoers.d" y dentro un archivo con una configuración, ésta será activada.
Podríamos hacerlo manualmente y funcionaria pero... hay un pero. Ne nuevo por las particularidades de QTS esos archivos no sobreviven a un reinicio.
Así que la única opción que nos queda es hacerlo mediante una tarea con autoarranque.
Afortunadamente esto si está en QTS mediante la activación de autorun.sh en este otro post.
Yo soy de los que recomiendo que ese autorun.sh llame a un segundo script sh.
Este segundo script es fácilmente editable sin tener que hacer los comandos "especiales" del post anterior para alterar al autorun.sh inicial.
Tanto si se hace de una forma o de otra, en el script hemos de agregar la siguiente línea
Code:
#agrega a elotrousuario como sudoers
mkdir /usr/etc/sudoers.d && echo "elotrousuario ALL=(ALL) NOPASSWD:ALL" > /usr/etc/sudoers.d/elotrousuario
He puesto una línea de comando, pero podian haberse separado perfectamente en dos.
Una para crear la carpeta y otra para crear el archivo
Con los cambios ya hechos, tras cada reinicio, se crea la carpeta "sudoers.d" y un archivo con el nombre del usuario conteniendo la configuración que evita la petición de la clave.
Hace poco, a raíz de aumentar la RAM de mi NAS, instalé de nuevo Qsirch. La búsqueda la hace perfecta desde dentro de la aplicación, pero no tengo manera de conectar con él desde la extensión de Firefox o Chrome. Esta extensión se instala sin problema, pero no es posible conectar con el NAS.
¿A alguien más le ha pasado? Ya no sé si estoy haciendo algo mal... Pongo el puerto 8080 o el 443 (en caso de https), pero nada.
Pues recientemente se me ha actualizado a macOS Sequoia (versión 15) y justo también se me actualizó el TS-264 a la versión 5.2.0.2860 y me es imposible acceder e iniciar sesión en el NAS.
Si me aparece en el Qfinder pero cuando intento acceder a el , me dice que no tengo permisos. Desde el navegador igual, imposible iniciar sesión y acceder a el.
Si me monta en el escritorio un volumen que tenía configurado con archivos multimedia...
Mi nivel es bastante básico...agradecería si alguien me puede echar un mano...
Nuestras nas por defecto ya tienen por defecto un comando accesible desde consola para comprimir 7z.
Está ubicado en la ruta "/usr/local/sbin" y el ejecutable "7z" en realidad es un script en bash que llama al programa "7z.orig"
En mi caso compruebo que es la versión 16.02 en varias nas
En una nas con una anciana CPU Marvell ARM
En una nas con AMD RX-421 ND
En una nas con un viejo Atom D2701
En una nas con Annapurna Labs Alpine AL314 Quad-core ARM Cortex-A15
Si nos fijamos en las capturas anteriores, vemos algunas diferencias en función de la CPU ya que pueden ser de 32 o 64 bit y los tipos de CPUs son Intel X86 y ARM.
Para poder instalar la última versión nos vamos a la web oficial de 7-zip.org y en su sección de descargas veremos que tenemos varias opciones.
Hemos de descargar la adecuada en función de nuestra arquitectura de nas.
Para instarlo, sólo hemos de descargar el paquete adecuado a nuestra nas y CPU.
En nuestros casos serían las versiones marcadas
Descargado el archivo , lo abrimos con nuestro 7z
Lo abrimos con un gestor de archivos comprimidos (por ejemplo el mismo 7z) y veremos que al ser .tar.zx hemos de abrirlo por dos veces (abrir el comprimido del comprimido). Si no lo has entendido, no me extraña que yo tampoco , echa una ojeada a las siguientes capturas:
Ahora al abrir el .tar vemos lo siguiente
Extraemos esos dos archivos a nuestro equipo y los copiamos a una carpeta de la nas.
La carpeta ha de ser una que esté en nuestro PATH.
Esto del PATH es una ruta que sigue nuestra nas cuando intentamos lanzar un ejecutable. Primero lo intenta en la carpeta donde estemos, luego en primera carpeta del APTm luego e, la segunda del PATH,...y así sucesivamente.
Podemos ver cual es nuestro PATH si en la consola escribimos "$PATH"
Pero el problema de hacerlo así es que esos archivos no sobreviven al reinicio de la nas y hemos de hacer una triquiñuela para que tras el inicio de la nas, se copien esos archivos a una carpeta del PATH.
Para ello activaremos el autorun.sh como se ve en este post
Descomprimiremos los archivos 7zz y 7zzs en una carpeta compartida (por ejemplo Scripts ubicada en CACHEDEV1_DATA)
Y agregaremos las siguientes líneas al script del autonicio (hay que variarlo en función de las rutas nuestras)
Code:
if [ ! -f /sbin/7zzs ] || [ ! -f /sbin/7zz ] ; then
cp /share/CACHEDEV1_DATA/Scripts/7zz /sbin/7zz
cp /share/CACHEDEV1_DATA/Scripts/7zzs /sbin/7zzs
chmod +x /sbin/7zzs
chmod +x /sbin/7zz
fi
Lo que hacen es comprobar que no existen en /sbin, los copia y les signa atributos de ejecución.
Si ya tenemos accesibles los dos archivos en una ruta del path y ejecutamos 7zzs veremos que ya funciona la nueva versión.
Ni que decir tiene que usar la versión mas nueva nos permitirá mas opciones y mejor compresión. Pero recordad que si tenemos scripts que llaman a 7z, debemos cambiarlo por 7zzs o bien eliminar el viejo y crear un alias "7z" para que llame al nuevo.
Recordad que este tipo de compresión:
- es asimétrica, se tarda en comprimir pero menos en descomprimir.
- nuestra nas no brillan por la potencia de su CPUs. Pero al ser máquinas 24x7 acabarán el trabajo si no tenemos urgencia.
La idea de comprimir no sólo se hace por el ahorro de espacio, también se hace por el ahorro de tiempo si tuviésemos que transferirlo a otro equipo o nube de almacenamiento.
En un cliente tengo un NAS de Qnap ya bastante antiguo que no tiene actualizaciones desde hace años, salvo alguna de seguridad. Es el modelo TS-259 Pro+, que me parece es del 2.012.
El caso es que está metido en el dominio de Windows Server y hace poco se ha cambiado el servidor y ahora tiene instalado Windows Server 2022 Standard. Los primeros meses ha funcionado bien, pero llevo ya unas semanas que un día un equipo y otro día otro equipo, es incapaz de acceder al NAS por el nombre Netbios, por el nombre del NAS, y hay que acceder por su IP.
El error que me da el NAS cuando intento acceder por su nombre Netbios es que fallan las credenciales, como si el usuario y la contraseña no fueran correctos. Que son correctas, claro.
Con IP no da problemas.
El tema es que hay en la empresa un montón de hojas de cálculo que van a diversas hojas para realizar macros y operaciones que están apuntadas al NAS por su nombre Netbios, no por letra de unidad o por su IP, por lo que acceder por IP no es una solución y cambiar todas las hojas de cálculo también es un follón de narices.
¿Sabéis porqué puede pasar eso? Ya tengo bastante asumido que habrá que cambiar el NAS, ya que da estos problemas, supongo, por su antigüedad y falta de actualizaciones, pero no sé si se me está escapando algo.
El NAS ha estado funcionando sin problemas todos estos años cuando tenía un servidor con Windows Server 2008 R2.
El NAS lo he vuelto a meter en el dominio, no ha dado error, dice que está Ok, pero sigue igual.
Buenas,
Soy nuevo en esto de los NAS y la verdad es que ando un poco perdido. He comprado un nas sencillo, el QNAP TS130. Es de segunda mano y me venía con un disco 3.5" que hace muuucho ruido. Me gustaría cambiarle el disco duro y poner un SSD manteniendo la info del disco actual. Tengo un Kingston A400 de 1TB y lo he pinchado en el Nas pero no me deja avanzar en la configuración del mismo. El Nas se queda con la luz verde parpadeando que significa que el disco no está formateado.
Preguntas:
- ¿Como formateo el disco? ¿Con reset de fábrica?
- ¿El Kingston A400 es recomendable para NAS?
- Se puede poner cualquier disco a estos cacharros? Veo que hay discos específicos para los NAS, pero claro son caretes.
Estoy dándole vueltas a la opción de la caché que promociona en sus NAS como opción. No sé si al final eso es muy buena idea, ya que parece ser que vuelca en esos discos m.2 nvme que hacen de caché los archivos de más uso para agilizar el proceso ¿pero qué sucede si se va la luz? Esos archivos entiendo se quedan en los discos caché y no sé si cuando arranca Qnap es capaz de detectar que se ha apagado mal y reorganiza los archivos que se hayan quedado en la caché a los discos duros normales para que no se pierdan datos o se pierden los cambios que no estén salvados.
En fin, que no termino de verlo porque algo he leído en la web de Qnap y no me ha dejado muy tranquilo.
La idea con la caché es poner dos discos duros de 500GB M.2 NVME para lo de la caché y 2 discos duros de 4TB en RAID 1 de W. Digital RED para los archivos. El uso va a ser de servidor de archivos de Word, Excel, PDF... trabajo de oficina.
Para este NAS había pensado en el TS-253E de 8GB de RAM, aunque también estoy dudando en irme a algo más profesional con el TS-473A que habéis hablado bien por aquí, ya con más discos, claro. Igual en este modelo que entran cuatro discos duros puedo optar por 4 x discos SSD de 2TB y me olvidaría de la caché. Yo creo que 6TB que creo me dejaría el RAID 5 tendría espacio de sobra para documentación durante muchos años.
Pero en fin, el tema es que no sé si fiarme de la caché o para el uso que le vamos a dar me recomendáis otra configuración o NAS.
Hola a todos, comento un poco el caso, NAS TS-228 con 2 HDD en Raid1, el NAS esta instalado en un pequeño estudio de arquitectura dando el servicio de almacenamiento compartido. Al parecer hace unos días empezó a dar pitidos y dejo de permitir el acceso a los directorios compartidos en Red. Me hacen llegar el NAS y al encenderlo me encuentro con indicador lumínico de uno de los discos parpadeando en rojo, indicando fallo en ese disco, hasta ahí nada fuera de lo habitual, esto se soluciona sustituyendo el disco y dejando que se reconstruya el Raid.
El problema surge cuando intento acceder por el panel web, al poner las credenciales de acceso este da error de usuario o contraseña incorrectos, pruebo con los datos de acceso por defecto, y para mi sorpresa, accede ofreciéndome el realizar la configuración inicial del NAS. Visto esto decido salirme y no continuar, hago cambio de HDD y dejo que se reconstruya el Raid, intento nuevamente iniciar sesión y sigue en el mismo estado, lo que me obliga a terminar de inicializar el NAS, obviamente no toco para nada la parte de configuración de los disco, solo datos de region, fecha y hora, etc. La cosa es que ahora tengo el NAS con un volumen heredado y desmontado, el cual no veo ni encuentro forma de montar dicho volumen para poder tener acceso a los datos, los cuales son muy importantes.
a alguno le ha pasado esto o algo parecido, o alguna idea de como proceder, gracias de antemano.
