Apartamento En Familia

Apartamento En Familia
Apartamento de playa para vacaciones. http://www.apartamentoenfamilia.es. Número registro HUTT-005768

viernes, 16 de junio de 2017

Migrando de owncloud 8.2 a nextcloud 11 de un servidor a otro en Ubuntu 17.04

Nextcloud es un completo software que nos permitirá sincronizar archivos, carpetas, calendarios y contactos entre múltiples dispositivos. Esto no es nada nuevo, ya que los servicios de Google lo hacen, pero este software nos permite tener el control total de todos nuestros datos, ya que dichos datos se almacenan localmente en nuestra red local, no se suben a ninguna nube pública ni servidor externo si no queremos.

Nextcloud está centrado específicamente en proporcionar a sus usuarios seguridad, privacidad y el control total de todos sus datos, de tal forma que sean totalmente transparentes. Este software es la siguiente generación de sincronización de archivos que empezó con ownCloud, sin embargo, Nextcloud es mucho más avanzado y está en continuo desarrollo por parte de su equipo y también por la comunidad ya que es de código abierto.

(Fuente: RedesZone)

En un tutorial anterior os explicaba como instalar owncloud:

Este tutorial mostrará un procedimiento para migrar nuestro servidor ownCloud v8.2 de una máquina, a otra máquina diferente en donde querremos tener Nextcloud. Si la migración se hace en la misma máquina, el procedimiento es practicamente el mismo si bien no hay que transferir las copias de la base de datos y archivos de una a otra. Una cosa que tenemos que tener clara es la escalera de migraciones que debemos realizar:
  • ownCloud 8.2 y 9.0 a Nextcloud 9.
  • ownCloud 9.0 y 9.1 a Nextcloud 10
  • ownCloud 9.1 a Nextcloud 10 or 11.
(Fuente nextcloud)

Esto quiere decir, que si tengo (como es el caso) un owncloud 8.2, si deseo pasarlo a nextcloud 12, tendré que hacer una migración previa a nextcloud 9. Entendido esto, vamos a hacerlo:

Descarga: https://nextcloud.com/install/
wget https://download.nextcloud.com/server/releases/nextcloud-9.0.58.zip
--2017-06-15 11:16:27--  https://download.nextcloud.com/server/releases/nextcloud-9.0.58.zip
Resolviendo download.nextcloud.com (download.nextcloud.com)... 88.198.160.133
Conectando con download.nextcloud.com (download.nextcloud.com)[88.198.160.133]:443... conectado.
Petición HTTP enviada, esperando respuesta... 200 OK
Longitud: 44682063 (43M) [application/zip]
Guardando como: “nextcloud-9.0.58.zip”
nextcloud-9.0.58.zip                          100%[======================>]  42,61M  7,99MB/s    in 5,7s    
2017-06-15 11:16:33 (7,50 MB/s) - “nextcloud-9.0.58.zip” guardado [44682063/44682063]
Luego descomprimimos con unzip: 

unzip nextcloud-9.0.58.zip

Y obtendremos el software listo para instalarlo. Pero nosotros en este tutorial lo que queremos es migrar de owncloud a nextcloud, y no hacer una instalación nueva. Para ello necesitaremos:

  • Instalar un nuevo servidor LAMP
  • Hacer copia de seguridad de la base de datos de owncloud y restaurarla en el nuevo servidor
  • Hacer copia de los archivos (./data) de owncloud y copiarlo en el nuevo servidor.
  • Hacer copia de seguridad de la configuración de owncloud (./config) y restaurarlo en el nuevo servidor.

Por ejemplo, en mi caso tengo una copia de seguridad de la base de datos de owncloud. Me la copio al nuevo servidor y la descomprimo. Luego:

CREATE DATABASE IF NOT EXISTS nextcloud;
mysql --user=root --password nextcloud < owncloud-sqlbkp.bak


Creamos el site nextcloud en el apache del nuevo servidor:

Alias /nextcloud "/var/www/nextcloud/"


  Options +FollowSymlinks
  AllowOverride All

 
  Dav off
 

 SetEnv HOME /var/www/nextcloud
 SetEnv HTTP_HOME /var/www/nextcloud

a2ensite nextcloud.conf


Tambien es aconsejable habilitar los siguientes módulos:
a2enmod headers
a2enmod env
a2enmod dir
a2enmod mime

Instalamos algunos paquetes php extras que nos irán bien
apt install php7.0-curl php7.0-json php7.0-cgi php7.0-xml memcached php-memcached php-zip php-mbstring php7.0-gd
systemctl reload apache2

Como el objetivo de este tutorial no es enseñar a instalar un owncloud o nextcloud, daremos por conocidos esos conceptos.

En este punto ya estamos preparados para poder realizar la migración:

http:///nextcloud/updater/

Ahora nos pedirá una clave de actualización. Esta será la que tengamos configurado en nuestro config.php, pero en el caso de no acordarnos la podemos regenerar desde el terminal :
php -r '$password = trim(shell_exec("openssl rand -base64 48"));if(strlen($password) === 64) {$hash = password_hash($password, PASSWORD_DEFAULT) . "\n"; echo "Insert as \"updater.secret\": ".$hash; echo "The plaintext value is: ".$password."\n";}else{echo "Could not execute OpenSSL.\n";};'
También se puede hacer por linea de comandos. De hecho, para servidores con gran cantidad de información es aconsejable ya que los tiempos de espera de PHP nos podrían cancelar la actualización.

sudo -u www-data php occ upgrade
Nextcloud or one of the apps require upgrade - only a limited number of commands are available
You may use your browser or the occ upgrade command to do the upgrade
  - Hint: You can speed up the upgrade by executing this SQL command manually: ALTER TABLE `*PREFIX*filecache` ADD COLUMN checksum varchar(255) DEFAULT NULL AFTER permissions;
Continue with update (y/n)
y
Set log level to debug
Checking whether the database schema can be updated (this can take a long time depending on the database size)
(...)

Al finalizar la actualización hacemos:

sudo -u www-data php occ maintenance:mode --off
Nextcloud is in maintenance mode - no app have been loaded
Maintenance mode disabled

Y .. ¡¡ tachán!! ya lo tendremos en Nextcloud 9!. Ahora toca actualizarlo hasta la 11. Para ello usaremos las propias indicaciones del nextcloud. Podemos hacerlo mediante linea de comandos o ayudándonos con el actualizador de nextcloud:
  1. Activar Modo mantenimiento
    sudo -u www-data php occ maintenance:mode --on
  2. Hacer copia de la configuración (config/config.php), base de datos y carpeta data
  3. Borrar el código antiguo de nextcloud y colocar la nueva versión
  4. Restablecer configuración (config.php) y carpeta data.
  5. Lanzar el comando para realizar la actualización
    sudo -u www-data php occ upgrade
  6. Desactivar Modo mantenimiento
    sudo -u www-data php occ maintenance:mode --off

martes, 27 de septiembre de 2016

OCFS2 (Oracle Cluster File System) + VMWare Multi-Writer

OCFS (Oracle Cluster File System) es un sistema de archivos de discos compartidos o sistema de archivos distribuido para clusteres de servidores de sistemas GNU/Linux desarrollado por Oracle Corporation distribuidos bajo los términos de la GNU General Public License.
La primera versión de OCFS se desarrolló con el objetivo de albergar los archivos de la base de datos de Oracle en entornos clusterizados.Con la segunda versión del sistema las características POSIX fueron incluidas.
OCFS2 (versión 2) fué integrada dentro de la versión 2.6.16 del kernel de Linux. Inicialmente se marcó como código experimental (Alpha-test). Esta restricción se levantó en la versión 2.6.19. Con la versión de kernel 2.6.29 se añadieron más funcionabilidades como ACLS (access control lists) y cuota 2

(Fuente Wikipedia

La idea básica de este sistema de archivos es, dado un servidor de almacenamiento, compartir dicho almacenamiento entre diferentes servidores. Para ello, crearemos un almacenamiento compartido (shared storage) e instalaremos un sistema de archivos capaz de trabajar en clúster. Esto es importante ya que si miramos de usar un disco compartido con un sistema de archivos que no tenga capacidades de cluster crearía inconsistencia de datos. Luego veremos un ejemplo. 
Este sería el esquema que planteo:


Para crear el disco compartido podríamos basarnos, por ejemplo, en VMWare creando un disco duro virtual con acceso de escritura desde cualquier máquina y luego activar los flags multi-writer. Como el objetivo de este blog no es enseñar a usar características de VMWare, os dejo el enlace para que podáis hacerlo si fuera necesario. Sino, podéis usar una SAN o cualquier otro sistema que conozcáis para compartir almacenamiento.
Por otro lado, necesitamos que el sistema de archivos esté preparado para trabajar con clúster y en esta ocasión trabajaremos con OCFS2. Para instalarlo en nuestro sistema usaremos apt:



Así pues:
apt-get install ocfs2-tools

Si tenéis una versión con escritorio también podeis instalar ocfs2console. Para este tutorial nos basaremos en servidores sin ventanas.

Lo primero que haremos es definir dos nodos que accederán al recurso compartido (disco compartido). Podrían ser tantos nodos como queramos, pero empecemos por dos. También declararemos un cluster que nos servirá para enlazar los nodos:

Creamos el archivo /etc/ocfs2/cluster.conf:

cluster:
node_count = 2
name = ocfs2

node:
ip_port = 7777
ip_address = 192.168.1.100
number = 1
name = node3
cluster = ocfs2

node:
ip_port = 7777
ip_address = 192.168.1.101
number = 2
name = node4
cluster = ocfs2

Es bastante sencillo entender la configuracón. Declaramos un cluster de dos maquinas (node_count = 2) al que llamamos ocfs2 (name = ocfs2). Luego declaramos dos nodos a los que le ponemos la ip que tienen (192.168.1.100 etc), les asignamos un nombre a cada nodo (name = mi_nodo1) y los enlazamos con el cluster definido (cluster = ocfs2). Como nota, deciros que el nombre del cluster 'por defecto' es ocfs2. Podéis cambiarlo, pero tenerlo en cuenta por si algo no os funciona. También tener muy en cuenta el sangrado del archivo. Si no tabulais correctamente el archivo no arrancará el servicio. Os dará un error como este:



Ahora vamos a cambiar un valor en el otro archivo 'importante' de configuración:
/etc/default/o2cb

Debéis cambiar el valor O2CB_ENABLED a true y dejarlo así:

O2CB_ENABLED=true

Esto lo que hará es que se cargue el driver al arrancar el sistema operativo, lo cual con casi toda seguridad es lo que querremos. 

Ya lo tenemos listo. Nos quedará reiniciar los servicios para que los cambios se apliquen:

service o2cb restart
service ocfs2 restart

Ahora bien, todo esto lo hemos hecho en un nodo. Para el otro nodo deberemos instalar también el paquete, editar el /etc/ocfs2/cluster.conf y /etc/default/o2cb.

Ahora sólo nos queda formatear el disco compartido (como es compartido, lo hemos de hacer solamente una vez en uno de los nodos) con el sistema de archivos ocfs2. No hace falta particionarlo si vamos a usar todo el disco. Entenderemos que nuestro disco compartido será, para este ejemplo, el /dev/sdb .

root@node3:/etc/ocfs2# mkfs.ocfs2 -b 4k -C 32K -L "Cluster-OCFS2" -N 4 /dev/sdb
mkfs.ocfs2 1.6.4
Cluster stack: classic o2cb
Label: Cluster-OCFS2
Features: sparse backup-super unwritten inline-data strict-journal-super xattr
Block size: 4096 (12 bits)
Cluster size: 32768 (15 bits)
Volume size: 4293918720 (131040 clusters) (1048320 blocks)
Cluster groups: 5 (tail covers 2016 clusters, rest cover 32256 clusters)
Extent allocator size: 4194304 (1 groups)
Journal size: 67108864
Node slots: 4
Creating bitmaps: done
Initializing superblock: done
Writing system files: done
Writing superblock: done
Writing backup superblock: 1 block(s)
Formatting Journals: done
Growing extent allocator: done
Formatting slot map: done
Formatting quota files: done
Writing lost+found: done
mkfs.ocfs2 successful

Para montar el disco compartido podemos editar el /etc/fstab añadiendo:

/dev/sdb /mnt/Cluster-OCFS2 ocfs2   defaults 0       0

y luego hacer mount -a.

Una vez hecho esto podremos ver que ya trabajamos con el cluster definido:

root@node3:/mnt# /etc/init.d/ocfs2 status
Configured OCFS2 mountpoints:  /mnt/Cluster-OCFS2
Active OCFS2 mountpoints:  /mnt/Cluster-OCFS2

Si montamos el disco compartido en los dos nodos, veremos que lo que vemos y escribimos desde uno tiene visibilidad total en el otro. 

Enlaces de interés:

jueves, 28 de abril de 2016

Arreglar 'No ha sido posible iniciar Dropbox' (dropbox permissions error)

Dropbox es un servicio de alojamiento de archivos multiplataforma en la nube, operado por la compañía Dropbox. El servicio permite a los usuarios almacenar y sincronizar archivos en línea y entre ordenadores y compartir archivos y carpetas con otros usuarios y con tabletas y móviles.1 También se puede ejecutar el programa WINISIS de UNESCO administrador de bases de datos textuales2 . Existen versiones gratuitas y de pago, cada una de las cuales tiene opciones variadas. La versión móvil está disponible para AndroidWindows PhoneBlackberry e iOS (Apple).

(Fuente Wikipedia)


La clave para arreglar este problema es siempre mirar en el archivo creado en el /tmp y fijarnos en la linea en donde sale el OperationlError. En mi caso (hay muchos otros si buscáis por internet) era este:

OperationalError: user-defined function raised exception

Para arreglar el problema he acudido al típico desinstalar e instalar programa, con el aderezo de que hay que borrar unas carpetas ocultas en tu carpeta personal (que no se encarga el purge). Así pues:

sudo apt-get purge nautilus-dropbox
cd ~
mv .dropbox .dropbox.old
mv .dropbox-dist/ .dropbox-dist.old
sudo apt-get install nautilus-dropbox

Luego sales de la sesión, vuelves a entrar y ya te pedirá de validarte en dropbox como una instalación nueva. 

martes, 26 de abril de 2016

APT y el mensaje "uses weak digest algorithm (SHA1)"

SHA-1 ha sido examinado muy de cerca por la comunidad criptográfica pública, y no se ha encontrado ningún ataque efectivo. No obstante, en el año 2004, un número de ataques significativos fueron divulgados sobre funciones criptográficas de hash con una estructura similar a SHA-1; lo que ha planteado dudas sobre la seguridad a largo plazo de SHA-1.
SHA-0 y SHA-1 producen una salida resumen de 160 bits (20 bytes) de un mensaje que puede tener un tamaño máximo de 264 bits, y se basa en principios similares a los usados por el profesor Ronald L. Rivest del MIT en el diseño de los algoritmos de resumen de mensaje MD4 y MD5.

(Fuente Wikipedia)

Desde la publicación de la distribución 16.04 LTS, el soporte para SHA-1 en el comando apt esta discontinuado. Así pues, obtenemos este mensaje de advertencia:

W: http://dl.google.com/linux/chrome/deb/dists/stable/Release.gpg: Signature by key 4CCA1EAF950CEE4AB83976DCA040830F7FAC5991 uses weak digest algorithm (SHA1)

No es nada que podamos hacer más que esperar que los encargados del repositorio den una nueva clave con un algoritmo compatible. Tampoco es muy alarmante dado que de momento es un simple 'warning' (pese a que resulta molesto). No existe ningún parámetro en apt tipo --sha1 . Así que simplemente nos queda esperar que se actualicen los repositorios (los oficiales ya estan actualizados).


Más información

  • https://bugs.chromium.org/p/chromium/issues/detail?id=596074
  • https://lists.debian.org/deity/2016/03/msg00197.html
  • http://askubuntu.com/questions/760796/how-to-fix-apt-signature-by-key-uses-weak-digest-algorithm-sha1-after-install
  • https://www.symantec.com/en/uk/page.jsp?id=sha2-transition


jueves, 3 de marzo de 2016

Git + Apache + LPAP (no gitweb)

Git (pronunciado "guit"2 ) es un software de control de versiones diseñado por Linus Torvalds, pensando en la eficiencia y la confiabilidad del mantenimiento de versiones de aplicaciones cuando éstas tienen un gran número de archivos de código fuente. Al principio, Git se pensó como un motor de bajo nivel sobre el cual otros pudieran escribir la interfaz de usuario o front end como Cogito o StGIT3 Sin embargo, Git se ha convertido desde entonces en un sistema de control de versiones con funcionalidad plena. 4 Hay algunos proyectos de mucha relevancia que ya usan Git, en particular, el grupo de programación del núcleo Linux.
El mantenimiento del software Git está actualmente (2009) supervisado por Junio Hamano, quien recibe contribuciones al código de alrededor de 280 programadores.

Imagen de http://www.danielnavarroymas.com/
Nuestra idea es crear un repositorio git en local y después poder acceder a él mediante el protocolo http/s (git over http) con validación en nuestro servidor LDAP. 

Así pues vamos paso a paso. Lo primero es crear un repositorio en local. Para ello creamos una carpeta y dentro de ella ejecutaremos git con el parámetro init:





root@eithel-server:/var/www/git# mkdir test.git
root@eithel-server:/var/www/git# cd test.git/
root@eithel-server:/var/www/git/test.git# git init
Initialized empty Git repository in /var/www/git/test.git/.git/
root@samsagaz:/var/www/git/test.git#

Vamos a ver como se ha inicializado nuestro directorio:
Pues muy bien, ya vemos que efectivamente tenemos una carpeta inicializada para poder trabajar con git. Así que hagamos un commit inicial para ver que tal:
root@eithel:/var/www/git/test.git# git add .
root@eithel:/var/www/git/test.git# git commit -m 'initial commit'
# En la rama master
#
# Commit inicial
#
nada que hacer (crear/copiar archivos y utilice «git add» para continuar)

Podemos hacer también git status para ver el estado del repositorio.
Pues bien, ya tenemos repositorio funcionando. Ahora queremos acceder por http/s y queremos que nos pida el usuario para que se valide por LDAP. 
Vamos a suponer en este artículo que ya tenemos el servidor Apache instalado. Así pues, ahora lo que vamos ha hacer es configurar nuestro git.conf :

SetEnv GIT_PROJECT_ROOT /var/www/git
SetEnv GIT_HTTP_EXPORT_ALL
SetEnv REMOTE_USER=$REDIRECT_REMOTE_USER
ScriptAlias /git/ /usr/lib/git-core/git-http-backend/


<Directory "/usr/lib/git-core*">
   Options ExecCGI Indexes
   Require all granted
</Directory>


<Directory /var/www/git>
Options ExecCGI Indexes FollowSymLinks
AllowOverride All
        Require all granted
</Directory>


<Location /git/test.git/>
DAV on
# SSLRequireSSL
Require all granted
AuthName "GIT Repo"
AuthType Basic
AuthBasicProvider ldap
AuthLDAPURL ldap://ldapserver:389/ou=People,dc=eithel?uid
AuthLDAPGroupAttributeIsDN off
AuthLDAPGroupAttribute memberUid
require user mi_usuario_LDAP
#Satisfy any
</Location>




Por otro lado nos tenemos que asegurar que los módulos de apache que necesitamos esten activos. Esto lo podemos saber haciendo:/usr/sbin/apache2ctl -t -D DUMP_MODULES

Necesitaremos los módulos authnz_ldap_moduleldap_module para la validación con LDAP y los módulos alias_moduleenv_module, dav_fs y cgi para el funcionamiento del enlace apache-git.

Si entramos en la carpeta del repositorio creado /var/www/git/test.git podemos ver que configuración tiene por defecto.

more config

Si queremos modificar valores podemos usar el comando git con el parámetro config

git config --file config http.receivepack true
git config --bool core.bare true

Por ejemplo podemos configurar el repositorio de esta manera (en este ejemplo dejaríamos modificar la rama principal):

[core]
repositoryformatversion = 0
filemode = true
bare = true
sharedrepository = 1
[receive]
denyNonFastforwards = true
[http]
receivepack = true

Configurar el servidor con las opciones que veais que más se ajustan a vuestras necesidades. Desde la parte cliente


Entonces desde el ordenador cliente, por ejemplo, podemos hacer:

cliente@mipc:/# git push origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 202 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To http://ediaz@repository-eithel/git/test.git
 * [new branch]      master -> master

Como podéis comprobar, el usuario usa el git sobre http y el http el cual se valida por LDAP.

Ahora según el uso que le vayáis a dar, es cuestión ya de ir configurando el respositorio y el cliente para, por ejemplo, excluir según que tipo de archivos del control de versiones mediante la creación del archivo .gitignore, etc.

jueves, 18 de febrero de 2016

Como solucionar problemas con ST8000AS0002-1NA17Z (8 Tb) en Linux (rsync, dd, cp...)


Si nos hemos comprado el flamante disco duro de Seagate y probado en nuestro Ubuntu (o cualquier otra distribución), veremos que lo detecta sin problemas y que parece funcionar bien. Pero como los que compramos este tipo de discos es porque probablemente lo queremos para soluciones de respaldo (backup), sabremos que al hacer rsync, dd, cp o cualquier otra instrucción contra este disco, hace que el kernel de un error y se nos queda en modo lectura (read-only). Un ejemplo de lo que podemos ver en el syslog es este:


Feb 10 08:57:59 eithel-server kernel: [149638.596415] ------------[ cut here ]------------
Feb 10 08:57:59 eithel-server kernel: [149638.596441] WARNING: CPU: 3 PID: 8153 at /build/linux-lts-vivid-whAhIw/linux-lts-vivid-3.19.0/fs/btrfs/super.c:260 __btrfs_abort_transaction+0x54/0x130 [btrfs]()
Feb 10 08:57:59 eithel-server kernel: [149638.596443] BTRFS: Transaction aborted (error -5)
Feb 10 08:57:59 eithel-server kernel: [149638.596444] Modules linked in: nouveau mxm_wmi wmi video ttm drm_kms_helper drm snd_hda_codec_hdmi i2c_algo_bit intel_powerclamp snd_hda_codec_via snd_hda_codec_generic snd_hda_intel coretemp snd_hda_controller snd_hda_codec kvm_intel snd_hwdep kvm snd_pcm snd_timer snd soundcore serio_raw shpchp 8250_fintek lpc_ich asus_atk0110 mac_hid lp parport btrfs xor raid6_pq pata_acpi psmouse r8169 ahci libahci mii pata_via
Feb 10 08:57:59 eithel-server kernel: [149638.596462] CPU: 3 PID: 8153 Comm: kworker/u32:29 Tainted: G          I    3.19.0-25-generic #26~14.04.1-Ubuntu
Feb 10 08:57:59 eithel-server kernel: [149638.596463] Hardware name: System manufacturer System Product Name/P7P55 LX, BIOS 1102    01/03/2011
Feb 10 08:57:59 eithel-server kernel: [149638.596475] Workqueue: btrfs-extent-refs btrfs_extent_refs_helper [btrfs]
Feb 10 08:57:59 eithel-server kernel: [149638.596476]  ffffffffc041ef40 ffff880002687c28 ffffffff817aed00 0000000000000000
Feb 10 08:57:59 eithel-server kernel: [149638.596478]  ffff880002687c78 ffff880002687c68 ffffffff81074d8a 0000000102687c68
Feb 10 08:57:59 eithel-server kernel: [149638.596479]  ffff880118f071e0 ffff8800d3c7b000 00000000fffffffb ffffffffc041b0b0
Feb 10 08:57:59 eithel-server kernel: [149638.596481] Call Trace:
Feb 10 08:57:59 eithel-server kernel: [149638.596489]  [] dump_stack+0x45/0x57
Feb 10 08:57:59 eithel-server kernel: [149638.596493]  [] warn_slowpath_common+0x8a/0xc0
Feb 10 08:57:59 eithel-server kernel: [149638.596495]  [] warn_slowpath_fmt+0x46/0x50
Feb 10 08:57:59 eithel-server kernel: [149638.596501]  [] __btrfs_abort_transaction+0x54/0x130 [btrfs]
Feb 10 08:57:59 eithel-server kernel: [149638.596508]  [] btrfs_run_delayed_refs.part.66+0x12c/0x2a0 [btrfs]
Feb 10 08:57:59 eithel-server kernel: [149638.596516]  [] delayed_ref_async_start+0x88/0xa0 [btrfs]
Feb 10 08:57:59 eithel-server kernel: [149638.596527]  [] normal_work_helper+0xc2/0x2b0 [btrfs]
Feb 10 08:57:59 eithel-server kernel: [149638.596537]  [] btrfs_extent_refs_helper+0x12/0x20 [btrfs]
Feb 10 08:57:59 eithel-server kernel: [149638.596540]  [] process_one_work+0x14f/0x400
Feb 10 08:57:59 eithel-server kernel: [149638.596541]  [] worker_thread+0x118/0x510
Feb 10 08:57:59 eithel-server kernel: [149638.596543]  [] ? rescuer_thread+0x3d0/0x3d0
Feb 10 08:57:59 eithel-server kernel: [149638.596546]  [] kthread+0xd2/0xf0
Feb 10 08:57:59 eithel-server kernel: [149638.596548]  [] ? kthread_create_on_node+0x1c0/0x1c0
Feb 10 08:57:59 eithel-server kernel: [149638.596552]  [] ret_from_fork+0x58/0x90
Feb 10 08:57:59 eithel-server kernel: [149638.596553]  [] ? kthread_create_on_node+0x1c0/0x1c0
Feb 10 08:57:59 eithel-server kernel: [149638.596555] ---[ end trace ce5daf4bc8891b5b ]---
Feb 10 08:57:59 eithel-server kernel: [149638.596557] BTRFS: error (device sde1) in btrfs_run_delayed_refs:2792: errno=-5 IO failure
Feb 10 08:57:59 eithel-server kernel: [149638.596680] BTRFS info (device sde1): forced readonly

En el ejemplo anterior vemos que he usado el sistema de archivos btrfs. Pues no os preocupeis, no es por el sistema de archivos. El mismo problema te dara cambiando las opciones de montaje del btrfs o probándolo con cualquier otro sistema de archivos ( ext2/3/4, jfs, zfs, xfs, ... ) a excepción de NTFS. Con NTFS no pasa. Podeis hacer vuestras pruebas y con casi total seguridad llegaréis a la misma conclusión.

Y.. ¿ahora que? Bueno, la clave esta en saber que el problema es de nuestro kernel. Así que actualizamos nuestro ubuntu 15.10 (wily) desde el repositorio para ver si lo arregla y seguimos sin arreglarlo:

Linux MiMaquina 4.2.0-27-generic #32-Ubuntu SMP Fri Jan 22 04:49:08 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Entonces ya podemos empezar a caer en la desesperación. Pero aun no esta todo perdido. Podemos mirar de ir más allá del kernel oficial de nuestro repositorio y bajarnos una actualización mayor. Para ello seguiremos el artículo ya publicado:
Una vez actualizado el sistema veremos que ya todos nuestros problemas han acabado y que el disco no se pone en sólo lectura al hacer rsync, dd o cp de gran cantidad de archivos.

Si queremos estar seguros de nuestro modelo de disco duro podemos utilizar los parámetros de hdparm según el artículo publicado anteriormente:


That u don't know what you've got 'til it's gone