Xiaomi IMILAB Mijia CMSXJ16A e Samba non vanno d'accordo

 Ho preso alcune camere wifi come queste:

Funzionano decentemente, non sono granché integrabili e si usano solo dall'app Mi Home. Ma la risoluzione è buona, la copertura dell'illuminazione IR notturna decente e sono abbastanza stabili (per lo meno 2 su 3). Saltuariamente si trovano in offerta a circa 25€, quindi ne ho fatto incetta.

A lavoro nessun problema, ho configurato un'utenza dedicata sul NAS e la cam vi riversa quello che registra (occhio che serve comunque una microSD).

A casa invece, non c'era verso di configurarle perché salvassero sul NAS casalingo su base Ubuntu.

Ravano nei log e trovo:

[2020/10/23 12:26:03.706346,  3] ../../source3/smbd/negprot.c:757(reply_negprot)

  reply_negprot: No protocol supported !

[2020/10/23 12:26:03.706480,  4] ../../source3/smbd/sec_ctx.c:319(set_sec_ctx_internal)

  setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0

[2020/10/23 12:26:03.706529,  5] ../../libcli/security/security_token.c:53(security_token_debug)

  Security token: (NULL)

[2020/10/23 12:26:03.706576,  5] ../../source3/auth/token_util.c:873(debug_unix_user_token)

  UNIX token of user 0

  Primary group is 0 and contains 0 supplementary groups

[2020/10/23 12:26:03.706648,  5] ../../source3/smbd/uid.c:503(smbd_change_to_root_user)

  change_to_root_user: now uid=(0,0) gid=(0,0)

[2020/10/23 12:26:03.706697,  4] ../../source3/smbd/sec_ctx.c:319(set_sec_ctx_internal)

  setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0

[2020/10/23 12:26:03.706736,  5] ../../libcli/security/security_token.c:53(security_token_debug)

  Security token: (NULL)

[2020/10/23 12:26:03.706778,  5] ../../source3/auth/token_util.c:873(debug_unix_user_token)

  UNIX token of user 0

  Primary group is 0 and contains 0 supplementary groups

[2020/10/23 12:26:03.706839,  5] ../../source3/smbd/uid.c:503(smbd_change_to_root_user)

  change_to_root_user: now uid=(0,0) gid=(0,0)

[2020/10/23 12:26:03.706887,  4] ../../source3/smbd/sec_ctx.c:319(set_sec_ctx_internal)

  setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0

[2020/10/23 12:26:03.706926,  5] ../../libcli/security/security_token.c:53(security_token_debug)

  Security token: (NULL)

[2020/10/23 12:26:03.706968,  5] ../../source3/auth/token_util.c:873(debug_unix_user_token)

  UNIX token of user 0

  Primary group is 0 and contains 0 supplementary groups

[2020/10/23 12:26:03.707038,  5] ../../source3/smbd/uid.c:503(smbd_change_to_root_user)

  change_to_root_user: now uid=(0,0) gid=(0,0)

[2020/10/23 12:26:03.707105,  4] ../../source3/smbd/sec_ctx.c:319(set_sec_ctx_internal)

  setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0

[2020/10/23 12:26:03.707152,  5] ../../libcli/security/security_token.c:53(security_token_debug)

  Security token: (NULL)

[2020/10/23 12:26:03.707197,  5] ../../source3/auth/token_util.c:873(debug_unix_user_token)

  UNIX token of user 0

  Primary group is 0 and contains 0 supplementary groups

[2020/10/23 12:26:03.707265,  5] ../../source3/smbd/uid.c:503(smbd_change_to_root_user)

  change_to_root_user: now uid=(0,0) gid=(0,0)

[2020/10/23 12:26:03.707322,  4] ../../source3/smbd/sec_ctx.c:319(set_sec_ctx_internal)

  setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0

[2020/10/23 12:26:03.707367,  5] ../../libcli/security/security_token.c:53(security_token_debug)

  Security token: (NULL)

[2020/10/23 12:26:03.707412,  5] ../../source3/auth/token_util.c:873(debug_unix_user_token)

  UNIX token of user 0

  Primary group is 0 and contains 0 supplementary groups

[2020/10/23 12:26:03.707479,  5] ../../source3/smbd/uid.c:503(smbd_change_to_root_user)

  change_to_root_user: now uid=(0,0) gid=(0,0)

[2020/10/23 12:26:03.707877,  3] ../../source3/smbd/server_exit.c:243(exit_server_common)

  Server exit (no protocol supported

In sostanza non riesce a negoziare un protocollo con il client.

Sul web consigliano di settare il protocollo minimo alla versione 1 di Samba, inserendo nel file di configurazione /etc/samba/smb.conf la riga:

client min protocol = NT1

Però non funziona. Provo anche con il valore "CORE" al posto di NT1 (anche se in realtà sono la stessa cosa). Poi ravano nell'help di Samba e trovo anche altri valori relativi al protocollo minimo. In particolare questo:

server min protocol = NT1

Bingo!

Ora va. Devo solo creare un'utenza dedicata:

sudo useradd cam 

sudo passwd cam

sudo smbpasswd -a cam 

e poi aggiungere lo share al file smb.conf:

[Cam]

   comment = Share per le CAMs

   path = /Path/Cam

   valid users = cam

   public = no

   writable = yes

   create mask = 0644

   directory mask = 0755

   ; if you set this, all files get written as this user

   force user = cam

Infine ricarico la configurazione di Samba:

sudo smbcontrol all reload-config

Fatto. 

 

ReadyNAS Duo V1 fail!

Quando un NAS smette di funzionare non è mail una buona notizia.

Soprattutto quando è un NAS proprietario, vecchio, su CPU Spark su cui nessuno vuole metterci le mani.

TRANNE TE

Quindi bando alle ciance e vediamo di recuperare qualcosa.

Il modello è Netgear ReadyNAS Duo (V1), con due dischi in mirror (RAID 1) da 500GB. Monta un OS linux-based, con l'ultimo firmware beta reperito sul forum netgear (4.1.18 T9, se non ricordo male). Dirai che è vecchio e che mi merito tutti i mali del mondo... beh, forse hai ragione. 

Riassumendo la situazione: probabilmente in seguito ad una mancanza di alimentazione, il NAS si accende (è già una cosa buona), i dischi girano (ancora meglio) ma non è raggiungibile ne da frontend ne da SSH/telnet (molto pessima). 

Provo con qualche riavvio, scollego uno e poi entrambi i dischi, ma nulla da fare. Si avvia ma è inutilizzabile. Non mi arrischio al reset, perché non vorrei perdere le varie configurazioni o, peggio, rischiare di perdere i dati.

La priorità è ovviamente verificare che siano ancora lì. 

Trovo un sistema per accedere via telnet:

• Rimuovo il disco 2 (per sicurezza)
• Avvio il NAS in Tech Support Mode
• Telnet (o SSH) sull'IP del NAS con username=root e pswd=infr8ntdebug
• Monto la partizione
• /bin/start_raid.sh
• mount /dev/hdc1 /sysroot

Vado su /sysroot e vedo che tutti i dati ci sono... fiuu!

Sollevato dalla buona notizia devo cercare il modo di metterli in salvo. Netgear ha fatto le cose per bene (meh...), quindi monto uno dei dischi su un PC linux (Ubuntu) e provo a montarlo. Nada. 

Scartabello un po sulla rete e scopro che usa LVM (che non conosco). Trovo una guida che parrebbe fare al caso mio, ma non funziona. Dopo un po' di prove, per fortuna, riesco. Ecco come:

Installa LVM (se già non ce l'hai):

• sudo apt install lvm2

Poi prepara una directory per il montaggio:

• sudo mkdir /dove/vuoi/montarlo

Poi montalo:

• sudo vgscan
• sudo vgchange -ay
• sudo lvdisplay
• fuse-ext2 -o sync_read,allow_other,rw+ /dev/c/c /dove/vuoi/montarlo

Come prima cosa mi copio le cose importanti sul disco di sistema, così posso usarlo come NAS temporaneo nel mentre che smanetto su quello reale. Fin qui tutto bene (relativamente parlando).

Purtroppo per lo scatolotto c'è ben poco da fare. Provo a skippare il check dei volumi, a svuotare la partizione di sistema dai log, a riflashare il firmware con un OS reinstall. Niente da fare.

Mi rassegno a resettare del tutto il NAS: in effetti ho fatto bene a non farlo alla cieca, perché avrei formattato i dischi e tanti saluti ai miei dati.

Dopo il reset completo finalmente il NAS si rianima: lo riconfiguro, ricreo le condivisioni e ci ricarico i dati prendendoli dal disco montato come di cui sopra (tramite rsync).

Reference:

https://community.netgear.com/t5/Using-your-ReadyNAS-in-Business/RND2000-Duo-v1-lockup-after-boot-OS-partition-full/td-p/1462451

https://kb.netgear.com/24874/How-do-I-access-the-boot-menu-on-my-ReadyNAS-Duo-NV-NV-X6-or-600

https://www.cyberciti.biz/faq/linux-mount-an-lvm-volume-partition-command/

http://technostuff.blogspot.com/2012/06/how-to-mount-disk-used-by-readynas.html