Header Ads

Compartición de archivos

9:49 , , , , , ,
Es común hoy en día encontrar organizaciones con redes de área local donde coexisten terminales conectados, con una topología definida o híbrida, con una variedad de sistemas operativos y hardware y uno de los servicios que presenta más problemas es la compartición de archivos, no solo por la naturaleza de la red local y su segmentación, sino por configuraciones erradas o cambio de versiones del producto que conducen a fallos. Tal es el caso de la compartición de carpetas con Samba.
Algunos administradores IT se enredan con los permisos (heredados), vetos y demás configuraciones que debe tener una compartición hecha por Samba y abrirle camino en el firewall para que todos sus usuarios puedan acceder a ésta unidad compartida desde su estación de trabajo. Es por esto que dedicaremos unas líneas para explicar de la manera más sencilla posible la implementación de comparticiones (Debian/Ubuntu). Y si bien existen front-end (como GAdmin-Samba GTK+ apt-get install gadmin-samba perteneciente al pack Gadmin tools) que pueden configurar Samba vía GUI, lo haremos por consola para mayor fiabilidad.
Instalación y Configuración
Instalamos samba 
apt-get install samba
Editamos el archivo de configuracion (vim, nano, gedit, etc)
 vim /etc/samba/smb.conf
Grupo de trabajo de Windows (Opcional) 
[global]
## Browsing/Identification ###
# Change this to the workgroup/NT-domain name your Samba server will part of
  workgroup = redlocal
Para este caso de ejemplo escogimos como Grupo de Trabajo "redlocal". Cámbielo a su gusto.
Compartiendo Archivos
Supongamos que vamos a crear una carpeta en el servidor Linux llamada publica, y en ella todos los usuarios de nuestra red local compartirán sus archivos de forma pública, pero solo accesible desde dentro de la red local. Como sabemos de antemano es una organización mediana, calculamos entonces que es más viable destinar un disco duro o una partición para alojar estos archivos, ya que con el tiempo los "gigas irán creciendo". Como no queremos que la llenen rápidamente con videos y música (que es lo que más consume), vamos a establecer sobre ella un 'veto' y finalmente le daremos permisos para que los usuarios puedan crear, eliminar y modificar los archivos de esta carpeta a su antojo.
Nota: Es bueno advertirles a nuestros lectores que este tipo de carpetas no es para manejar información sensible, ya que es pública, así sea interna de la organización y que deben siempre hacer copia de respaldo de los archivos que en ésta coloquen, ya que cualquier usuario puede acceder a un archivo o carpeta y eliminarla. De acuerdo a lo expuesto, al final del archivo smb.conf deberán colocar lo siguiente: 
[publica]
 comment = publica
 delete readonly = yes
 writeable = yes
 path = /home/servidor/publica
 veto files = /*.mp3/*.wmv/*.wma/*.mpg/*.3gp/*.mpeg/*.mkv/
 browseable = yes
 valid users = nobody
Lo anterior quiere decir que tenemos una carpeta llamada publica, en la ruta  home/servidor/publica que se puede navegar por ella ( browseable = yes), y que no se pueden almacenar una serie de archivos con determinadas extensiones ( veto files), tales como música (.mp3, wma, etc) y videos (mpeg, 3gp, etc). Pueden extender el veto a las extensiones que quieran (.inf, .msi, .cab, exe, etc), o eliminar el veto y permitir de todo.
Ahora creamos la carpeta en nuestro servidor, (previamente establecida en el  smb.conf y le damos los permisos. 
mkdir -p /home/servidor/publica/
chmod 777 /home/servidor/publica/

# servicios de Samba (Start/Stop/Restart/Status)
service smbd start
service smbd stop
service smbd restart
service nmdb start
service nmdb stop
service nmdb restart
service nmdb status
service smbd status
service --status-all
Y si decidimos asignar un disco duro físico "esclavo" a esta carpeta (no una partición o simplemente una carpeta dentro de nuestro servidor), entonces el paso adicional es montar el disco duro en la carpeta "publica". Conectamos el disco duro al servidor, nos aseguramos que este desmontado, abrimos el terminal y ejecutamos blkid para determinar el UUID del disco. 
usuario@usuario:~$ blkid -c /dev/null
/dev/sda1: UUID="3bb21fce-2952-47e2-bf1e-39a81dcba822" TYPE="ext4" 
/dev/sda2: LABEL="Data" UUID="780C74D60C74900C" TYPE="ntfs" 
/dev/sda4: UUID="115a57b3-ee36-4598-a000-833b402d23a6" TYPE="ext4" 
/dev/sda5: UUID="917990ec-d630-414f-89ab-580g83fb3d1b" TYPE="swap"
En este ejemplo tenemos conectado a nuestro servidor un disco duro (sda2) en formato NTFS (que es un formato nativo de Windows), con la etiqueta o nombre "Data" y vamos a agregarlo al fstab del servidor, para que en el arranque el disco duro siempre se monte en la carpeta compartida. La ventaja de dedicar un disco a las carpetas compartidas empresariales es la misma de dedicar un disco duro para almacenar los discos virtuales, explicada anteriormente. Editamos el fstab y agregamos el UUID. 
gedit /etc/fstab
#Entry for /dev/sda2 :
UUID=780C74D60C74900C /home/servidor/publica ntfs-3g defaults,locale=es_ES.UTF-8  0  0
Y ahora montamos el disco rígido en la carpeta publica:
mount -a
Automatizando el proceso
Otra manera de hacerlo es inyectando directamente al cron, la partición NTFS. Primero la detectamos con:/div> 
fdisk -l | grep NTFS | cut -d" " -f1
# y el resultado es, por ejemplo:
/dev/sda6
Y luego creamos la carpeta y metemos la particion:
mkdir -p /media/windows >/dev/null 2>&1
sudo echo "/dev/sda6 /media/windows ntfs-3g auto,user,exec,nosuid,nodev,nofail,defaults,umask=000 0 0" >> /etc/fstab
Lo anterior se puede guardar en un script y ejecutarlo. Los parámetros son de elección de usuario. Digite el comando id en consola para saber los parametros de su equipo y poderlos agregar a la línea, por ejemplo uid, git, unmask (000 significa 777), etc.
Acceder a la carpeta publica desde un terminal Linux
Si queremos conectarnos desde un terminal linux a la "publica" del servidor y que cada vez que iniciemos nuestro terminal, siempre aparezca montada (similar a las carpetas de red que se montan con la letra Z por defecto en Windows), entonces agregamos en el fstab del terminal del "usuario", lo siguiente:
//192.168.1.2/publica /home/usuario/publica cifs sec=ntlm,defaults,uid=1000,gid=1000,user=servidor,password=abc123,_netdev    0    0
En el ejemplo anterior, la IP del servidor que tiene la carpeta o unidad compartida es la 192.168.1.2, la cual será montada en la ruta home/usuario/publica del terminal Linux de la red local. Si la compartida tiene clave entonces deberá incluir esta clave y usuario en la línea. Para este ejemplo usamos  user=servidor,password=abc123. Caso contrario, elimine de la línea del fstab. Tenga en cuenta que debe crear primero la carpeta compartida "pública" en el terminal del usuario ( /home/usuario/publica) y darle los permisos chmod antes de proceder a montarla.
Nota: En el caso de que un terminal linux de la red local quiera acceder a la carpeta privada del servidor y montarla en el terminal es necesario primero agregar el usuario al servidor y luego asignarle la clave. Para agregar, ver y eliminar usuarios samba. 
# Agregando usuario al samba
sudo adduser usuario
# Para ver usuarios agregados al samba
sudo pdbedit -L
# Para eliminar usuarios agregados al samba
sudo smbpasswd -x usuario
# Para eliminar usuarios completamente del sistema
sudo userdel usuario
Asignando clave al usuario agregado:
usuario@usuario:~$ sudo smbpasswd -a usuario
[sudo] password for usuario: 
New SMB password:
Retype new SMB password:
Parámetros adicionales
El parámetro  allow host, establece que solo determinados terminales sean los que accedan a esta carpeta compartida. 
allow hosts = 192.168.1.40 # si quieres que accedan solo desde una ip determinada
Para modificar la seguridad:
security = user
Para ponerle clave al usuario de Samba (clave de ejemplo: abc123):
sudo smbpasswd abc123
Para establecer los usuarios que van a acceder a la compartida:
valid users = servidor # en este caso solo se accede con el servidor
valid users = nobody # en este caso accede todo el mundo
Creando usuario de Samba:
sudo adduser servidor
Rendimiento
El rendimiento de samba depende de muchos factores. Velocidad del disco duro y sus cables de datos, dma, el hardware del servidor, sistema operativo y versión, la arquitectura de la red local, etc. En el caso específico de los discos duros o carpetas compartidas en el servidor o discos en red, las tasas de transferencia pueden caer cuando se transporta datos entre particiones diferentes (Ej: NTFS/ntfs-3g, RAID5/softRAID Linux) o cuando los discos son de distintas tecnologías (SATA vs ATA). La tasa de transferencia "normal" de un disco duro moderno SATA no debe ser inferior a 60 MB/sec.
usuario@usuario:~$ sudo hdparm -t /dev/sda
[sudo] password for usuario: 
/dev/sda:
 Timing buffered disk reads: 204 MB in  3.01 seconds =  67.72 MB/sec
No existe una regla general para optimizar las tasas de transferencia entre la red local y una carpeta compartida "publica" con Samba, pero se puede mejorar la optimización aplicando algunas técnicas conocidas como Samba Tuning (aunque no representa mejoras significativas en algunos entornos) con agregar unas líneas a la configuración y aumentar el buffer de envío y recepción. Por ejemplo, agregamos a la sección [Global] de smb.conf. 
use sendfile = yes
strict locking = no
read size = 65536
read prediction = true
max xmit = 65535
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF=65535 SO_RCVBUF=65535
read raw = yes
write raw = yes
max connections = 65535
max open files = 65535
oplocks = yes
deadtime = 15
getwd cache = yes
Nota: Los valores más comunes para SO_RCVBUF y SO_SNDBUF son 8192, 64240 y 65535. Puede activar o desactivar "read raw" y "write raw" en dependencia de su hardware y software e ir comprobando la tasa de transferencia hasta obtener un rendimiento óptimo.
Firewall
Ahora solo falta autorizar los puertos del Samba en el Firewall Iptables para que los usuarios de la red local puedan acceder sin problemas.
# ACCESO DE LA LAN A CARPETA COMPARTIDA (PUBLICA) EN EL SERVIDOR (SAMBA)
for mac in `sed $route/macs-redlocal`; do
 $iptables -A INPUT -i eth1 -m mac --mac-source $mac -p tcp -m multiport --dports 135:139,445 -j ACCEPT
 $iptables -A INPUT -i eth1 -m mac --mac-source $mac -p udp -m multiport --dports 135:139,445 -j ACCEPT
done
Donde:
$iptables=/sbin/iptables
$route/macs-redlocal # es la ruta home/servidor/acl/macs-redlocal (acl que contiene todas las macs de nuestra red local)
eth1 # es la interfaz en el servidor de la red local (eth0 es la interfaz de internet del servidor)
Logs
Muchas máquinas Windows, sobre todo XP, consultan varios puertos tcp y udp del Samba (135:139 y 445) pero normalmente solo se conectan a uno. En ocasiones esto genera un mensaje en los logs de tipo sm-sta; una alerta por sendmail, que es un programa de mensajería interna de Linux. ( Manual). Puede corregir esto, bien sea seleccionando en el archivo smb.conf un solo puerto de escucha, lo cual no es muy recomendable: 
smb ports=139
O ejecutar en el terminal con privilegios:
makemap hash /etc/mail/aliases.db < /etc/mail/aliases
O instalar o desinstalar sendmail:
sapt-get install sendmail
apt-get remove sendmail
O usar postfix en reemplazo de sendmail:
apt-get install postfix
Compartición por otros sistemas
Samba presenta algunas limitaciones, entre ellas que no puede actuar como controlador de dominio de Active Directory, que  actúa como BDC para un Windows PDC (y viceversa), son los  permisos heredados y los  controles de permisos en NTFS, con comparticiones en redes segmentadas, entre otras limitaciones, dada su "avanzada edad". Es por esta razón que los administradores IT recurren a otras soluciones, como es el caso de HTTP File Server (HFS) o Secure Copy (SCP). La ventaja de HFS es que es portable y puedes crear tu propio servidor compartido en una memoria usb, ya que utiliza la plataforma web y con esto garantiza mayor compatibilidad con cualquier sistema (con Samba puede ser más complicado), sin embargo es un ejecutable de Windows y depende de Wine para correr en plataformas Linux, lo cual no siempre es una alternativa viable. Un buen tutorial de HFS puede consultarlo  AQUI. Por su parte, SCP es un protocolo y programa a la vez bastante estable y puede cubrir muchas de estas necesidades, en especial si se trata de backups "seguros", o montar carpetas con acceso remoto.
Blackhold nos trae una solución ingeniosa para montar una carpeta remota y sincronizarla, tan solo usando ssh y rsync para la sincronización y un script o fstab para el montaje.
Instalamos en nuestro equipo sshfs:
apt-get install sshfs
Compartimos las claves con el servidor en el cual tenemos el disco duro remoto conectado:
# cd /root/.sshmen
# ssh-keygen -t rsa
# ssh-copy-id -i id_rsa.pub root@10.139.39.76
En la maquina remota tenemos el disco montado en /mnt/hd y en la local queremos montarlo también en /mnt/hd 
# mkdir /mnt/hd
# sshfs root@10.139.39.76:/mnt/hd/ /mnt/hd
Ahora para montarlo en el arranque agregamos las respectivas líneas en /etc/fstab o creamos un script:
#!/bin/bash
sshfs root@10.139.39.76:/mnt/hd/ /mnt/hd
mount -n -t simfs /mnt/hd /var/lib/vz/root/100/mnt/hd -o /mnt/hd
Entornos Windows
Para los amantes de Windows (Server), pueden echar mano de  File Screening Management para realizar el veto de archivos o carpetas compartidas (share) y  Network Access Protection para evitar virus y malware, Para mayor información sobre este punto visite:
También pueden emplear Applocker para bloquear programas y muchas otras cosas. Computerhoy nos trae un buen tutorial sobre el uso de esta aplicación.
Montaje de unidades compartidas por Samba en terminales Windows con diferentes credenciales.
Al contrario de Linux (que permite múltiples conexiones con un servidor utilizando credenciales diferentes), Windows solo permite conectarse a un servidor con la misma credencial. Esto puede representar un problema si en nuestro samba del servidor local tenemos varias carpetas compartidas.
Veamos el siguiente ejemplo:
Como en el caso anterior, supongamos que tenemos configurado en nuestro servidor dos carpetas compartidas; una llamada "pública" (que no tiene contraseña), destinada para todos los usuarios de nuestra red local puedan compartir cualquier cosa, y una segunda carpeta llamada "privada" (que tiene contraseña), solo para almacenar copias de seguridad, archivos sensibles, etc. En el smb.conf quedaría de la siguiente manera:
Carpeta compartida pública:
[publica]
 comment = publica
 delete readonly = yes
 writeable = yes
 path = /home/servidor/publica
 veto files = /*.mp3/*.wmv/*.wma/*.mp4/*.mpg/*.3gp/*.mpeg/*.mkv/
; browseable = yes
 valid users = nobody
 security = share
Carpeta compartida "privada":
[privada]
 comment = privada
 delete readonly = yes
 writeable = yes
 path = /home/servidor/privada
; browseable = yes
 security = user
 valid users = server
Donde valid users = server es el nombre del usuario samba del servidor y la contraseña que le haya asignado al momento de crearlo. Si intentamos conectarnos a la carpeta pública desde un terminal Windows no habría problemas, basta con buscar el servidor en la red y ver las carpetas compartidas y montar una de ellas. Para el caso de la "pública",  nos conectamos como unidad de red. Sin embargo al intentar conectarnos a la carpeta "privada", Windows nos arrojará un mensaje de error similar al siguiente:
Múltiples conexiones a un servidor o recurso compartido por el mismo usuario, utilizando más de un nombre de usuario, no están permitidas. Desconecte todas las conexiones anteriores al servidor o recurso compartido y vuelva a intentarlo
Esto se debe a que cuando utilizamos las credenciales de usuario para conectarse a un recurso compartido de red desde un equipo basado en Windows, la carpeta de red especificada actualmente se asigna mediante otro nombre de usuario y contraseña. En otras palabras Windows no acepta conexiones a carpetas compartidas que tengan usuarios y contraseñas diferentes. Para solucionarlo, conéctelo a la primera carpeta compartida (pública), por el método tradicional, ya sea buscando la carpeta directamente en el servidor, o en ejecutar:
 \\servidor\compartida
Y para el caso de la segunda carpeta compartida (privada) que tiene usuario y contraseña, conéctela mediante la ip del servidor. Ejemplo:
\\192.168.1.2\privada
Donde la ip del servidor es 192.168.1.2 (cámbiela según su red). Y seguido coloca las credenciales (usuario y contraseña). De esta manera ya podrá utilizar ambas carpetas sin entrar en conflicto de credenciales.
Security User
Samba trae por defecto activada la directiva security = user. Esto trae como consecuencia que si en las carpetas compartidas no se especifica la seguridad, Samba tomará por defecto que la seguridad le pertenece al usuario. Para solucionarlo, especifique siempre la seguridad a usar en cada carpeta compartida, o en su defecto busque en el smb.confla línea security = user y coméntela, y luego en cada carpeta compartida especifique que tipo de seguridad le va a asignar. En el ejemplo de arriba, para la carpeta "publica" usamos security = share y para la privada security = user. Lo mismo aplicaría para impresoras y demás comparticiones de samba.
Linux shares mapped as network drives in Windows. Image by  techgage
Samba 4
Con con la llegada de Samba 4, los problemas en lugar de disminuir, aumentaron, ya que sus diseñadores no se molestaron en corregir las fallas de la versión, cuando ya estaban liberando la siguiente. Asumiendo que no tenemos problemas con  SELinux (restricciones sobre la lectura y escritura de la carpeta compartida), para solucionar muchos males heredados de versiones previas a Samba 4, lo mejor es eliminarlo y reinstalarlo: 
apt purge -y samba samba-common smbclient system-config-samba
rm -rf /etc/samba /etc/default/samba /var/cache/samba
apt autoremove && apt -y update && apt -y dist-upgrade
apt -y install libnss-winbind* libpam-winbind* samba* smbclient system-config-samba winbind*
apt -f install
Una vez hecho esto, hay que hacer unos pequeños ajustes al archivo de configuración (/etc/samba/smb.conf) que harán que su Samba funcione mejor. 
Según  mit.edu han surgido informes recientes de clientes Microsoft Windows con problemas de compatibilidad con servidores de seguridad a nivel de recurso compartido. Para solucionarlo edite  smb.conf y reemplace en la sección [global]: 
security = share
# por
security = user
Y:
map to guest = bad user
por
map to guest = Bad Password
En el caso de carpetas públicas lo recomendado es asignarlas al grupo "nobody.nogroup" para evitar problemas de conexión con Windows. Ejemplo: (carpeta pública: "compartida").
mkdir -p compartida
chown -R nobody.nogroup compartida
chmod -R 777 compartida
También se recomienda desactivar las reglas obsoletas syslog:
# syslog only = no
# syslog = 0
Un mensaje frecuente que vemos en los logs es similar a este:  Samba name server USER is now a local master browser for workgroup WORKGROUP on subnet 192.168.1.16, que se repite cada vez que el servicio de samba reinicia:
Para prevenir que  Samba haga esto como un intento de controlar la red local (Domain Controller Windows NT Server, o similares) se recomienda agregar a la sección [global] lo siguiente: 
domain master = no
prefered master = no
local master = no
Establecer el hostname:
sudo hostnamectl set-hostname $HOSTNAME
Y verifique con:
cat /etc/hostname
Una  vulnerabilidad reciente detectada en Samba, identificada con  CVE-2017-2619 puede permitir a un cliente malicioso acceder a áreas no exportadas del servidor de archivos mediante una ruta de enlace simbólico. Para evitarlo actualice a la última versión y edite el smb.conf y agregue a la sección [global] el siguiente parámetro (y luego reinicie samba): 
# Symlink race allows access outside share definition
# https://www.samba.org/samba/security/CVE-2017-2619.html
unix extensions = no
Otra situación que se puede presentar con Samba 4 es la caída constante del servicio  nmbd
Esto se debe a la exclusión de localhost (lo) en la línea de interfaces. Para solucionarlo agréguelo de acuerdo a las  especificaciones oficiales: 
bind interfaces only = yes
interfaces = lo eth0
Aunque si Samba presenta conflictos con systemd (algo muy frecuente),  puede desactivar  bind interfaces only< /div>
Pero tenga en cuenta que al hacerlo Samba solo dependerá de los puertos abiertos en el firewall y no de la interfaz de red asociada:
bind interfaces only = no
Otro problema que puede presentarse en la compartición de archivos es con el directorio /var/lib/samba/usershares, y pueden salir mensajes como este:
Esto puede ser generado por muchas causas. Una de ellas es el malware (que se está pasando de los PCs Windows a la carpeta compartida, que está montada como unidad de red en los PCs conectados a Samba, asumiendo que la partición donde se encuentre la carpeta compartida sea NTFS).
Una posible solución es evitar que otros, que no sean el propietario, escriban o renombren archivos en esa carpeta y activando  Sticky bit: 
chmod 1775 /var/lib/samba/usershares/
chmod +t /var/lib/samba/usershares/
Y agregar en la sección Global de smb.conf la línea: 
usershare path =
Otra situación que se puede presentar si compartimos una partición NTFS dentro de un servidor con Linux (también se puede presentar con ext4) es la seguridad. Suponiendo que editamos  /etc/fstab para agregar una línea para montar nuestra unidad de red similar a la siguiente: 
//192.168.0.10/share /home/user/share cifs noauto,user,password,sec=ntlm,exec,nosuid,nodev,nofail,uid=1000,gid=1000,_netdev 0 0
Al intentar montar la unidad se presenta el típico error 22:
mount error(22): Invalid argument
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
Y si verificamos el log  /var/log/kern.log encontramos lo siguiente: 
No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount.
CIFS VFS: Unable to select appropriate authentication method!
CIFS VFS: Send error in SessSetup = -22
CIFS VFS: cifs_mount failed w/return code = -22
En este caso, la falla está en el parámetro  sec=ntlm (security=ntlm) que está "deprecated" (obsoleto) y podemos solucionando, bien sea eliminando este parámetro (recomendado) o agregando el parámetro  vers=1.0 a la línea de montaje del fstab (no recomendado).
Otro mensaje muy común es sobre el número límite de Windows  rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384). Para solucionar este problema, edite el archivo  /etc/security/limits.conf y agregue la línea: 
*  -  nofile  16384
Otro asunto considerado crítico es la vulnerabilidad  CVE-2017-7494, aprovechada por los ransomwares. En este caso lo mejor es actualizar Samba a las versiones 4.4.14 o superior (verifique con  smbd -V y consulte las  versiones vulnerabilidad en Ubuntu). Si no puede actualizarlo (compilarlo) puede agregar a la plantilla Global: 
nt pipe support = no
Nota: Esta regla impide que los clientes accedan a cualquier punto final de canal con nombre, sin embargo esto puede deshabilitar algunas funcionalidades de cara a los clientes (Windows, Linux, etc), por tanto si intenta conectarse a un recurso compartido (ej: \\share o \\192.168.0.1 etc) puede que la conexión sea rechazada. Lo mejor es que si no puede actualizar Samba a la versión indicada o superior, antes de aplicarla esta regla, conecte todos los terminales de su red local al recurso compartido y luego aplique los cambios. Como medida adicional a esta vulnerabilidad, se recomienda bloquear en el firewall el puerto 61422. Ejemplo Iptables: 
/sbin/iptables -t mangle -A PREROUTING -p tcp --dport 61422 -j DROP
Finalmente, guarde cambios y reinicie el equipo. Finalmente pruebe su  smb.conf para verificar que todos los parámetros están correctos, con el comando: 
testparm
Y si todo sale bien, reinicie los servicios:
systemctl restart smbd.service nmbd.service winbind.service
Sin embargo hay una falla de Samba 4, que no se puede solucionar con un simple cambio en la configuración. Si revisamos los logs (en algunos equipos) veremos el mensaje:
systemd[1]: Reloading LSB: start Samba SMB/CIFS daemon (smbd)
Este mensaje es normal que aparezca regularmente al reiniciar los servicios. Lo que no es normal es que se repita cada 5 minutos aproximadamente, y en cuestión de horas congestione los logs de samba. Muchos  blogs hablan sobre el tema y al parecer  afecta a algunas distribuciones de Linux; incluso es considerado un  Bug. Desafortunadamente la solución a esta falla de Samba depende en gran medida de la configuración de las interfaces de red del equipo donde esté instalado.
NetworkManager es una especie de demonio o más bien un frontend (de iproute, dhclient, wpa_supplicant y ppp) que sirve para editar las conexiones de red, de una manera cómoda en el escritorio de Linux (sea cual sea). Es bastante intuitivo y facilita las conexiones, sobre todo las redes inalámbricas. Pero existe otro archivo llamado  /etc/network/interfaces que hace exactamente lo mismo, con la diferencia que nos permite poner valores estáticos de configuración de nuestras interfaces de red, lo cual es bueno, ya que impide alteraciones en los parámetros por personas no autorizadas (se modifica con permisos de superusuario (sudo) o root), brindando una mayor seguridad que NetworkManager. Usualmente se utiliza para configurar las interfaces de red en servidores proxy y otros tipos de servidores en redes locales. Estos dos "mecanismos" de interacción con las interfaces de red no siempre se llevan bien, y por lo general sucede que al ingresar información al archivo "interfaces", NetworkManager no lee adecuadamente la información de este archivo o simplemente queda inutilizado. El resultado de esta "pelea" afecta a Samba en su versión 4x (no podemos confirmar que esto suceda con versiones anteriores).
En resumen, Samba mantiene buenas relaciones con NetworkManager, ya sea con IPs estáticas o DHCP, pero tiene problemas con la información de red DHCP que pongamos manualmente en el archivo "interfaces". En concreto, la falla de Samba radica en que no interpreta bien la regla DHCP. Ejemplo: 
auto eth0
iface eth0 inet dhcp
Esto genera el reinicio constante de los servicios de Samba y mensaje  reloading  lsb start samba smb/cifs daemon (smbd), causando desconexiones de los recursos compartidos. Paradójicamente no sucede lo mismo con la información en "interfaces" que contenga IPs estáticas, la cual Samba lee correctamente. Ejemplo: 
auto eth0
iface eth0 inet static
address 192.168.0.10
netmask 255.255.255.0
broadcast 192.168.0.255
network 192.168.0.0
gateway 192.168.0.1
dns-nameservers 8.8.8.8 8.8.4.4
Entonces la solución para evitar el colapso de Samba es, si tenemos un servidor en producción con una o varias interfaces de red (ej: una para internet y otra para la red local), sin importar el tipo de interfaz (wifi, eth, etc.) se recomienda desinstalar NetworkManager y configurar el archivo "/etc/network/interfaces" y asignar a las tarjetas de red, direcciones IPs estáticas (fijas).
Caso contrario; si tenemos un terminal Linux para nuestro trabajo diario en una red local, lo recomendado es que maneje sus conexiones con NetworkManager (si va a usar NetworkManager, asegúrese de tener el archivo  /etc/libuser.conf con los permisos adecuados. Si no lo tiene puede crearlo desde root).
Es necesario aclarar que estas fallas no afectan a todas las distribuciones de Linux ni a todas las versiones, por tanto recomendamos que revise sus logs, para cerciorarse, antes de aplicar las correcciones propuestas. Finalmente no olvide abrir en su firewall los puertos Samba (137, 138, 139 y 445 tcp/udp).
Asignatura pendiente
Desafortunadamente Samba aún es muy limitado, por ejemplo sigue sin brindar soporte para establecer límites en cuanto a la capacidad de directorios compartidos (y mucho menos a subdirectorios dentro del directorio compartido), y la única manera de hacerlo es  asignando cuotas de disco... o haciendo trampas con imágenes montadas.
Ejemplo: A continuación, crearemos una imagen llamada  share.img, de 1 GB pero puede ser de la cantidad que quieran, con un bloque de 1024 bytes, que es el recomendado para crear la imagen inicial y así no recargar el sistema durante la creación, en el directorio  test que será montada en el directorio  share (que es el directorio compartido para usuarios (deben crear primero las carpetas y asignarle propietario -chown- y permisos -chmod-).
1. Creando la imagen de 1 GB (1048576). Puede usar  esta calculadora para determinar los valores para la imagen en Kb y determinar el  tamaño del bloque 
dd if=/dev/zero of=/home/user/test/share.img bs=1024 count=1048576
2. Creando el sistema de archivos (ext2/ext3/ext4) con  mke2fs. 
sudo mke2fs -L share.img -j /home/user/test/share.img
Por defecto crea en ext3. Para especificar ext4 agregue la opción -t
sudo /sbin/mke2fs -t ext4 -L share.img -j /home/user/test/share.img
También puede formatear la partición en ext4 con:
sudo mkfs.ext4 /home/user/test/share.img
Reemplace mkfs.ext4 por mkfs.ext3 o mkfs.ext2 si va a usar ext3 o ext2. O mkfs.vfat (mkfs -t vfat 32 -F /dev/hda1 o mkfs.vfat -n nombre /dev/sdc1). Si  no quiere reservar block use el parámetro -m 0
3. Opcional: Incrementando el bloque a 8786 (de 4k) (Solo funciona con particiones simples. La imagen no debe estar montada)
sudo resize2fs -M /home/user/test/share.img
Opcional: Cambiando la etiqueta a la imagen (Donde "prueba" es el nombre que se le asignará a la unidad)
sudo e2label /home/user/test/share.img prueba
4. Verifique la imagen que está correcta antes de montarla:
sudo e2fsck -f -y /home/user/test/share.img
Nota: Esto generará una carpeta llamada lost+found que puede ser eliminada
5. Montando la imagen en el directorio compartido "share" y permisos sobre lo montado
sudo mount -t ext4 /home/user/test/share.img -o loop /home/user/share
sudo chmod 1777 /home/user/share
Este procedimiento se puede automatizar con  el siguiente script. 
# ejemplo smbd.conf
[alexandra.delarosa]
   comment = alexandra.delarosa with 5MB
   path = /mnt/smb_discs/alexandra.delarosa
   read only = no
   browseable = yes
   guest ok = yes
[arnaldo.hernandez]
   comment = arnaldo.hernandez with 5MB
   path = /mnt/smb_discs/arnaldo.hernandez
   read only = no
   browseable = yes
   guest ok = yes
[gustavo.flores]
   comment = gustavo.flores with 10MB
   path = /mnt/smb_discs/gustavo.flores
   read only = no
   browseable = yes
   guest ok = yes

# script:
LISTAUSUARIOS=`cat /tmp/usuarios.txt|sort`
RUTA_DISCOS="/smb_disks/smb_drives"
MOUNT_SMB="/mnt/smb_discs"
TMPSAMBACONF="/tmp/samba.virt.conf"

echo > $TMPSAMBACONF
mkdir -p `echo $RUTA_DISCOS`

for X in $LISTAUSUARIOS
  do echo $X | awk -F , '{print "asignando " $2 "MB a usuario "$1}'
  USUARIO=`echo $X | awk -F , '{print $1}'`
  PRE_ESPACIO=`echo $X | awk -F , '{print $2}'`
  let ESPACIO=`echo $PRE_ESPACIO`*1024
  dd if=/dev/zero of=$RUTA_DISCOS/$USUARIO.img bs=1024
  count=$ESPACIO
  /sbin/mke2fs -L $USUARIO -j $RUTA_DISCOS/$USUARIO.img
  mkdir -p $MOUNT_SMB/$USUARIO
  mount -t ext3 $RUTA_DISCOS/$USUARIO.img -o loop $MOUNT_SMB/$USUARIO
  echo "[$USUARIO]
  comment = `echo $USUARIO" with "$PRE_ESPACIO"MB"`
  path = /mnt/smb_discs/$USUARIO
  read only = no
  browseable = yes
  guest ok = yes    " >> $TMPSAMBACONF
done

echo "espacio usado en $RUTA_DISCOS: "
du -smh $RUTA_DISCOS/*.img
du -smh $RUTA_DISCOS/
mount -l | grep $MOUNT_SMB
echo "CHECK $TMPSAMBACONF AND ADD IT TO YOUR /etc/samba/smb.conf"
Para redimensionar consulte  AQUI. De esta manera se limita el almacenamiento. También se puede hacer con subdirectorios dentro del directorio compartido, pero tenga en cuenta que debe incluir estas imágenes a montar en el fstab para que arranquen con el sistema. Esperemos que algún día Samba incluya esta posibilidad nativamente y así evitarnos este engorroso procedimiento de tener cuotas de disco o montar imágenes.
Post recomendado:  Veto Files

Post a Comment

Con la tecnología de Blogger.