Montar un NAS casero con una Raspberry Pi y Samba lleva siendo un tema recurrente en el blog desde 2013. El proceso funciona bien, pero implica varios pasos manuales: formatear el disco, montar la partición, editar smb.conf, gestionar usuarios, reiniciar servicios. Para quien quiera saltarse todo eso, un proyecto reciente que vi en /reddit y que está publicado en GitHub tiene una propuesta directa: un instalador que hace todo eso por ti desde un menú de terminal. Aunque tiene ahora mismo unas limitaciones que son decisión de diseño y entiendo que son correctas por el espíritu del proyecto.
El proyecto se llama NasberryPi, está publicado por WastelandSYS y acaba de llegar a la versión 0.3.0, publicada el 30 de junio de 2026. Es código abierto bajo licencia GPL-3.0, escrito principalmente en Python con scripts de instalación en Shell, y suma 61 commits en la rama principal.
Qué hace NasberryPi
La idea central es sencilla: conectas un disco USB a la Raspberry Pi, ejecutas sudo nasberry y desde ese momento tienes un panel de terminal desde el que controlas el almacenamiento y el uso compartido en red. No hace falta tocar ningún fichero de configuración a mano.
El flujo de trabajo tiene cuatro pasos. Primero, el asistente de configuración detecta automáticamente los discos conectados y te guía para elegir el dispositivo y el punto de montaje. Segundo, montas el almacenamiento en modo NAS. Tercero, configuras el usuario de Samba. Cuarto, arrancas el uso compartido. Si el propio escritorio ya ha montado el disco en otra ruta, NasberryPi lo detecta como mounted elsewhere y pregunta antes de moverlo a modo NAS, en vez de tocarlo sin avisar.
Desde Windows accedes con \\hostname\Public y desde macOS y Linux con smb://hostname/Public y también te da la IP desde el propio panel de Nasberry Pi por si no funciona el DNS interno por algún motivo. En Android o iOS sirve cualquier gestor de ficheros compatible con SMB, como CX File Explorer o la app Archivos de iPhone.
Estados del NAS y herramientas de recuperación
NasberryPi define cinco estados, lo que ayuda a entender en todo momento qué está pasando. En Offline el almacenamiento está desmontado y el uso compartido detenido. En Mounted el disco está montado, aunque no necesariamente compartido en red. En Shared el disco está montado y el recurso compartido activo. El estado Safe Mode desactiva los servicios de uso compartido hasta que los reanudas manualmente, mientras que Panic Lock es una parada de emergencia inmediata de todos los recursos.
Antes de cualquier cambio en la configuración de Samba, el proyecto valida el nuevo fichero y guarda una copia de seguridad con marca de tiempo en /etc/samba/smb.conf.nasberry.<timestamp>.bak. Para diagnosticar problemas hay un comando específico, sudo nasberry doctor, que revisa el almacenamiento, los permisos, la configuración y los requisitos del sistema. Si algo falla en Samba, sudo nasberry repair-samba recrea y valida la configuración del recurso compartido.
El PIN que protege ciertas acciones dentro de NasberryPi es una capa adicional que actúa como «doble check». No sustituye a la seguridad de la cuenta Linux, a las contraseñas de Samba ni al cifrado del disco.
Instalación de NasberryPi en Raspberry Pi OS
El proyecto funciona en cualquier sistema de la familia Debian que tenga apt-get, lo que incluye Raspberry Pi OS, Debian, Ubuntu y Kali Linux ARM. Ha sido probado en Raspberry Pi 4B, Raspberry Pi 5 y Zero 2W.
Para instalarlo, clona el repositorio y ejecuta el instalador:
git clone https://github.com/WastelandSYS/nasberrypi.git
cd nasberrypi
chmod +x install.sh uninstall.sh
sudo ./install.sh
El instalador añade Samba automáticamente si no está presente y registra el comando nasberry de forma global. Para lanzar el panel:
sudo nasberryEl primer arranque real pasa por sudo nasberry setup. El asistente detecta los discos disponibles, te pregunta qué usuario Linux tendrá acceso al recurso y te obliga a crear el PIN antes de montar nada. Después monta el disco, configura su sección gestionada de Samba conservando lo que ya tuvieras y pide la contraseña SMB para ese usuario. Al terminar, deja en pantalla las instrucciones de conexión desde Windows con la IP del propio equipo.
Almacenamiento, recursos compartidos y desinstalación
Para el almacenamiento, el proyecto recomienda formatear el disco en ext4. Es el sistema de ficheros nativo de Linux, el que da mejor rendimiento y el que menos problemas da con los permisos en un servidor de ficheros. Ya lo comenté en la guía de Samba de hace años: FAT32 y NTFS son formatos de Windows y aquí solo traen complicaciones.
Una nota práctica que ha cambiado con la 0.3.0: antes, instalar NasberryPi ponía Samba en modo de dispositivo dedicado y desactivaba cualquier recurso compartido personalizado que tuvieras. Ahora ya no es así. NasberryPi delimita su propia sección dentro de smb.conf con marcadores y solo edita esa parte, así que el resto de tu configuración de Samba se conserva tal cual. El fichero anterior se sigue guardando como copia de seguridad antes de tocar nada.
La 0.3.0 también añade soporte para varias carpetas compartidas, algo que antes se limitaba a un único recurso llamado Public. Con sudo nasberry shares puedes añadir, quitar, activar o desactivar carpetas, y marcar cualquiera de ellas como solo lectura. Cada carpeta queda registrada en /etc/nasberry/shares.json, separado de la configuración principal en /etc/nasberry/config.ini.
Para desinstalar, sin eliminar los datos:
cd nasberrypi
sudo ./uninstall.shCon --dry-run puedes ver qué haría la desinstalación sin aplicar cambios. Con --purge elimina también la configuración de NasberryPi y los ajustes de Samba que gestiona.
Dos limitaciones que conviene tener claras
NasberryPi tiene dos limitaciones que conviene conocer antes de instalarlo. No es persistente: si reinicias la Raspberry Pi, el disco se desmonta y el recurso compartido se apaga, así que hay que volver a entrar en el panel y elegir Start sharing files cada vez. Y gestiona un único disco: las carpetas múltiples de
nasberry sharesson subcarpetas del mismo disco montado, no discos independientes. Para un uso puntual no es un problema, pero como NAS permanente con varios discos, hoy por hoy se queda corto.
¿Es seguro el código? Lo he revisado
Cuando un script se ejecuta como root y toca el almacenamiento, la configuración de red y los servicios del sistema, además de leer el README hay que intentar echar un vistazo al código, si no podemos solo con ayuda de IA.
Lo primero es buscar patrones que suelen dar problemas. No hay ninguno. El proyecto no usa shell=True, ni eval, ni exec, ni os.system con texto variable. Todos los comandos del sistema se ejecutan pasando listas de argumentos, que es la forma correcta de evitar la inyección de órdenes a través del intérprete de comandos.
El punto más delicado de un proyecto así que añade funcionalidades a usuarios suele ser «el nombre de usuario que tecleas» y que acaba escrito dentro de smb.conf. Si ahí se colara un salto de línea o ciertos caracteres, se podrían inyectar directivas maliciosas en la configuración de Samba. NasberryPi valida ese nombre antes de usarlo: rechaza espacios y los caracteres peligrosos, y además exige que el usuario exista de verdad en el sistema. Hay incluso un test que intenta inyectar una directiva admin users = root con un salto de línea y comprueba que queda bloqueada.
La escritura de la configuración también está bien planteada. El proyecto hace copia de seguridad del smb.conf actual y escribe la sección que gestiona en un fichero temporal. La valida con testparm y solo entonces reemplaza esa sección con una operación precisa, dejando intacto el resto del fichero. Si la validación falla, restaura la copia. El fichero de configuración propio se guarda con permisos 0600, accesible solo por root.
Cómo protege la contraseña y las dependencias
El PIN merece una mención aparte. No se guarda en texto plano: se almacena con PBKDF2-HMAC-SHA256, 200.000 iteraciones y una «pizca de sal» aleatoria. La verificación usa una comparación resistente a ataques de temporización. Es, básicamente, lo que recomiendan las guías de seguridad actuales. Aun así, el propio autor avisa de que ese PIN es una capa adicional para evitar sustos y errores.
Otros dos detalles a valorar positivamente. El proyecto usa solo la biblioteca estándar de Python, sin dependencias externas, así que no hereda riesgos de paquetes de terceros. Y no toca /etc/fstab, que es el error clásico capaz de dejar una Raspberry Pi sin arrancar por una línea mal escrita: el montaje se hace bajo demanda. Por último, se pueden ejecutar los 54 tests unitarios incluidos y confirmar que pasan todos.
Conviene matizar un punto. El repositorio tiene la creación de issues restringida, así que no encontrarás reportes públicos de la comunidad. La ausencia de incidencias solo refleja que no hay un canal abierto donde registrarlas; no garantiza que el proyecto esté libre de fallos. Además, sigue siendo un proyecto joven, todavía por debajo de la versión 1.0. Por eso conviene probarlo primero con un disco prescindible, tal como aconseja el propio autor.
Arranque por USB sin microSD ni NVMe
Dudas a la hora de probarlo: si la Raspberry Pi arranca directamente desde un disco USB, sin microSD ni NVMe, ese disco contiene el sistema operativo. ¿Cómo evita NasberryPi ofrecértelo como almacenamiento para compartir? Formatear o compartir por error el disco de arranque dejaría el sistema inservible, así que este detalle es importante.
La respuesta tranquiliza. El filtrado se basa en dónde está montada cada partición, no en el tipo de disco ni en cómo está conectado. Al listar los candidatos, NasberryPi descarta cualquier partición montada en las rutas del sistema: /, /boot, /boot/firmware y /home. Como en un arranque por USB el sistema operativo vive precisamente en esas rutas, esas particiones quedan fuera de la lista. Da igual que el sistema esté en un USB en lugar de una microSD o un NVMe, porque el criterio es el punto de montaje, no el medio.
En el mismo paso, el proyecto también descarta las particiones de intercambio y los dispositivos de RAM comprimida, que tampoco tendría sentido compartir.
En mi caso lo he comprobado con hardware real: un Compute Module 5 con IO board, que arranca desde la eMMC de 32 GB integrada en el módulo, no desde una microSD ni desde USB. El único candidato que ofreció el asistente fue un SSD NVMe de 238 GB conectado a la placa. Es uno de los discos de segunda mano que ya analicé en otro artículo, donde además era de los que permitían subir la velocidad del enlace PCIe. La eMMC de arranque ni apareció en la lista, lo cual confirma que el filtrado por punto de montaje funciona igual sea cual sea el tipo de almacenamiento de arranque, no solo en USB.
El caso de la partición extra y la segunda protección
Queda un detalle que conviene conocer. El sistema de puntuación que ordena los candidatos da preferencia a los discos marcados como extraíbles, y un disco de arranque por USB suele marcarse así. Pero como sus particiones de sistema ya se han eliminado antes por estar montadas en /, nunca llegan a esa fase. El único escenario teórico sería una partición adicional vacía y sin montar dentro del propio disco de arranque, que sí podría aparecer como candidata. No sería el sistema operativo, pero sí un trozo del mismo disco físico, y el asistente la mostraría antes de que confirmes nada.
Como segunda red de protección, la comprobación previa al setup añade más filtros. Se niega a montar el NAS si el punto de montaje es un enlace simbólico, si ya está ocupado por otro dispositivo o si no está vacío. En la práctica, para un arranque por USB el comportamiento es el esperado: NasberryPi no te ofrecerá el disco del sistema.
NasberryPi frente a Open Media Vault
La comparación más probable que puedas pensar será con Open Media Vault, que lleva años siendo la opción de referencia para un NAS con Raspberry Pi. Las diferencias son claras.
OMV es un sistema operativo completo con interfaz web, gestión de usuarios avanzada, plugins, soporte para varios protocolos y herramientas de monitorización. NasberryPi es un script de administración que se instala sobre el sistema operativo que ya tienes. No ocupa casi espacio, no cambia el sistema base y se puede desinstalar sin rastro.
Si ya tienes una Raspberry Pi funcionando con Raspberry Pi OS para otras cosas, NasberryPi tiene sentido: le añades la función de servidor de ficheros en red sin cambiar nada más. Si el objetivo desde el principio es dedicar la placa a ser un NAS con todas las herramientas, OMV sigue siendo la opción más completa. Es muy útil para compartir en momentos concretos un disco o unos archivos que tengas y necesitas que están disponibles en la red de casa. Habrá que seguir la pista al proyecto, ya que ahora mismo tiene otras carencias importantes como: no se arranca de forma automática y no permite más de un disco compartido a la vez.
NasberryPi no sustituye a Open Media Vault; cubre un caso de uso diferente. Para quien ya tiene una Raspberry Pi activa y quiere compartir un disco USB en red sin complicarse con interfaces web ni sistemas operativos alternativos, es una solución práctica, limpia y reversible.
Más información en el repositorio oficial: github.com/WastelandSYS/nasberrypi.
