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

Accedere a Samba da client Samba

Dopo mille peripezie sono riuscito a settare a dovere Samba sul NAS (Ubuntu 20.04). Provando ad accedere da un client Ubuntu 16.04 sembrava funzionare tutto, poi dopo qualche giorno non sono più riuscito a navigare sul server da Nautilus (l'interfaccia grafica per la gestione dei file).
Da altri client (LibreELEC, VLC, Android, Windows 10) invece continuava a funzionare. Molto strano.

Gira che ti rigira installo "smbclient" sul cliente non funzionante e dopo averlo avviato ricevo questo errore:

andrea@Computer:~$ smbclient //hal/Archivio -U kodi

WARNING: The "syslog" option is deprecated

Enter kodi's password: 

protocol negotiation failed: NT_STATUS_INVALID_NETWORK_RESPONSE

Inizio a googlare questo errore ed arrivo a questa pagina, dove comprendo che dovrebbe essere un problema di versione del protocollo. Inserendo infatti il parametro "-m smb3" in smbclient, il tutto funziona. Per risolvere consigliano di inserire alcuni parametri:

client min protocol = smb2

client max protocol = smb3

nel file di configurazione di Samba del server:

sudo nano /etc/samba/smb.conf

e, nello specifico, nella sezione [Global], per poi riavviare il servizio:

sudo service smbd restart

Eseguo ma, come puoi ben immaginare, non funziona una cippa. Mi accerto tramite un trick di star editando il file di configurazione corretto (modifico il nome del file di log e riavvio il servizio, trovando il log con il nuovo nome ho la conferma che il file di configurazione che sto editando è quello corretto).
In altre pagine trovo le medesime indicazioni, ma il tutto continua a non funzionare. Arrivo infine qui dove capisco che il file di configurazione di Samba è sia sul server che sul client.

Bingo.

Edito il file smb.conf sul client, inserendo dopo alcune prove questi parametri nella sezione [Global]:

client min protocol = SMB2

client max protocol = SMB3

min protocol = SMB2

max protocol = SMB3

Riavvio il servizio sul client e testo con smbclient.
Funziona.
Provo con Nautilus.
Funziona.

Alleluja.