Cohesity SmartFiles — share SMB

contesto

Serviva uno share SMB aziendale per un gruppo ristretto di utenti, con due requisiti forti: accesso trasparente (niente popup di credenziali per chi è già loggato in dominio) e restore in autonomia dei file cancellati/modificati, senza dover aprire un ticket né entrare nella UI del cluster.

Cohesity SmartFiles espone tutte queste capability via la primitiva View: un file-share logico su uno Storage Domain, con protocollo selezionabile (SMB, NFS, S3) e ACL integrate con AD.

approccio

Prerequisiti verificati: cluster già joinato al dominio AD, uno Storage Domain disponibile (DefaultStorageDomain), e almeno un client in rete raggiungibile dal cluster.
Creazione della View: SmartFiles → Views → Create View, nome Share_SteGio, protocollo SMB. Per l'indirizzo di accesso si usa l'IP con cui si raggiunge la Cluster UI via browser — se la pagina VIPs è vuota, quello è l'IP giusto.
Permessi tramite gruppi AD: in More Options → Users ho inserito i domain users che devono poter leggere e i gruppi autorizzati a scrivere. Tutto il resto del dominio ha accesso read-only automatico dalla Subnet Allowlist.
Verifica da client: da un PC Windows membro del dominio, \\10.1.1.31\Share_SteGio in Esplora File. Nessun prompt di credenziali, share aperta immediatamente. Test negativo: un utente fuori dal gruppo di scrittura vede i file ma riceve Access denied su New → Folder.
Protection Group + snapshot: ho agganciato la View a un Protection Group con policy di snapshot ricorrenti (frequenza e retention configurate secondo esigenze). Il primo snapshot parte automaticamente al Protect.
Restore self-service: sui client Windows gli snapshot appaiono come Previous Versions nelle proprietà della cartella/file — elenco cronologico di punti di ripristino, a cui l'utente accede senza toccare Cohesity.

outcome

Share accessibile senza credenziali aggiuntive per tutti i domain users.
Scrittura vincolata ai soli gruppi autorizzati — confermato da test negativo con un utente esterno al gruppo.
Restore self-service dei file storici via Esplora File → Proprietà → Versioni Precedenti: zero ticket al team IT per recuperi di routine.
Snapshot automatici secondo policy: retention e frequenza governate centralmente dal Protection Group.

constraints

Subnet Allowlist: è il punto che rompe più spesso. Se la subnet del client non è nell'allowlist della View, lo share semplicemente non appare, senza un messaggio d'errore comprensibile. Prima riga di debug: sempre lì.

VIP vs IP della UI: quando la pagina VIPs è vuota, il cluster risponde sull'IP della UI stessa — ma questa scelta non è ovvia dalla documentazione standard e porta spesso a tentativi di mount su IP sbagliati.

Feature Windows-dependent: "Previous Versions" è integrato nativamente solo nei client Windows. Client macOS e Linux vedono lo share ma non la UI degli snapshot: per loro il restore resta una operazione amministrativa lato Cohesity.

lezioni

Delegare i permessi di scrittura a gruppi AD (non a utenti singoli) rende lo share gestibile nel tempo: aggiungere una persona al team è una modifica in AD, non in Cohesity.
Il passaggio "invisibile" per l'utente finale — niente popup, niente credenziali — è quello che decreta il successo o il fallimento di una share in produzione. La parte tecnica è breve, la parte UX è tutto.
Avere il restore come funzione self-service cambia il carico sull'helpdesk più di qualsiasi altra scelta infrastrutturale. Un utente che può ripristinare un file da solo non apre un ticket.
Nella diagnosi di "share non raggiungibile", l'ordine di verifica è: (1) subnet allowlist, (2) join AD ancora valido, (3) IP usato dal client, (4) protocolli abilitati sulla View. Quasi sempre è il punto (1).