Errore "contattare amministratore di sistema" per i permessi dopo copia file

Ciao a tutti! Vorrei chiedervi una mano per capire cosa sia successo e come evitare che ciò ricapiti.

Ieri stavo ordinando alcune cartelle sul mio NAS fatto in casa (TrueNAS-13.0-U6.8), via SMB in Windows 11. Ho tagliato e poi incollato una cartella, sempre sul NAS, cosa che non mi ha mai creato problemi. Ieri invece la cartella si è incollata dopo molti minuti, ma risulta non apribile. Compare l’errore nel titolo. Provato anche da Ubuntu e macOS con lo stesso risultato.

Sono riuscito, via FTP, a verificare che la cartella esiste e che è piena ed ho dunque copiato, sempre via FTP, tutti i file in un disco del pc da cui stavo operando.

Come mai è accaduta questa cosa? Dovrei semplicemente evitare di fare taglia/incolla di una cartella, sempre sul NAS, per non incappare nello stesso problema?

Ciao!
Hai fatto benissimo intanto a recuperare i file in qualche modo, giusto per stare sicuri.

IMHO, quando succedono cose strane via SMB, mi viene sempre da pensare si tratti di errori di rete o di permessi che possono portare a lock - timeout o metadata “sporchi”.
Verifica innanzitutto i permessi su quel dataset, o se fosse una cartella in un dataset che siano applicati correttamente in maniera ricorsiva per il tuo utente. Potrebbe bastare a riavere accesso via SMB ai file.
Altra cosa che mi sento di consigliarti, avendolo sperimentato in prima persona: Core non funziona per niente bene con le schede di rete Realtek - praticamente presenti in tutte le schede madri consumer di fascia medio-bassa… a me mandava proprio in crash tutto il nas durante i trasferimenti un po’ più corposi :smile:

1 Like

Ciao e grazie innanzitutto per la risposta e per i consigli.

Premetto che, da quando ho creato utenze e datasets, ovvero all’inizio di questo progetto TrueNAS, non ho poi più toccato nessun parametro (essendo alle prime armi con TrueNAS, trovata una configurazione funzionante, ho preferito non muovere più niente!).

Questa la configurazione del dataset “incriminato”:

Per quanto riguarda invece la scheda di rete, il pc da cui sfoglio il NAS ha due porte ethernet: una Intel 1gb ed una Realtek 2.5gb, che è quella che uso da sempre.

Se dovesse venir fuori che questa scheda in uso è il problema di tutto, potrei comunque pensare di passare alla Intel, considerando che potrebbe bastarmi come velocità di scambio dati.

Così su due piedi mi verrebbe da dire che potrebbe bastare riapplicare user - group e spuntare apply permissions recursively. Vale la pena per dare un’occhiata prima di andare a toccare le impostazioni però: entra nella shell (dal tuo pc, non usare quella ultrabuggata nella GUI :smile: ) e vedi posta pure l output sul dataset di destinazione (penso sia quello che hai postato giusto?)
ls -l mnt/tank/Giuseppe e poi getfacl mnt/tank/Giuseppe.
Altra cosa importante, che prima non ti avevo menzionato: hai impostato i job periodici per eseguire gli snapshot? Sono la cintura di sicurezza perfetta in questi casi

1 Like

@oxyde grazie innanzitutto per tutti questi consigli e aiuti!

Allora: partiamo dal fatto che non ho impostato job periodici per gli snapshot semplicemente perchè non sono abbastanza documentato sulla cosa! Quindi dovrei prima capire di che si tratta e poi eventualmente procedere…eventuali consigli e/o guide ovviamente sono ben accetti! :smiley:

Poi, per quanto riguarda i due comandi, ecco gli output:

drwx------+  61 giuseppe  utenti    362 Sep 27  2024 Foto
drwx------+   4 giuseppe  utenti      4 Oct 15  2023 GameS
drwx------+   2 giuseppe  utenti     28 Jun  4  2023 hp win7 drivers
drwx------+   2 giuseppe  utenti     11 Feb 15  2023 ISO
d---------+  10 giuseppe  utenti     10 Jan 29  2023 Mac SVB
drwx------+   6 giuseppe  utenti      6 Mar 29  2025 ouiea
drwx------+   8 giuseppe  utenti      8 Feb  4  2023 PluginS
drwxr-xr-x    9 giuseppe  utenti     33 Oct  5 16:36 SASIO 2025
d---------+  16 giuseppe  utenti     21 Dec  8 12:59 SVB

Le due cartelle “incriminate” sono “SVB” e “Mac SVB”, che hanno effettivamente come permessi solo “d”. Direi quindi che, applicando i permessi, come dicevi tu a inizio post, dovrei rivederle.

Ecco l’altro output:

# file: mnt/tank/Giuseppe
# owner: giuseppe
# group: utenti
            owner@:rwxp--aARWcCos:-------:allow
            group@:------a-R-c--s:-------:allow
         everyone@:------a-R-c--s:-------:allow

1 Like

Sì, ti confermo che secondo me riapplicando i permessi ricorsivamente al dataset dovresti risolvere il problema. Una volta fatto puoi verificare ovviamente usando lo stesso comando e provando via SMB :smile:

Per quanto riguarda gli snapshot in zfs, te la faccio breve e semplice: essi non sono altro che un’istantanea del file system al momento in cui vengono registrati; occupano spazio nella pool (solo quando i file in esso cambiano), quindi quando vengono “scattati” automaticamente è bene impostare un periodo di “retention” adeguato (dopo di cui vengono eliminati). Si impostano nella GUI (in Core non ricordo esattamente dove però), se non hai esigenze particolari il mio consiglio è una fotografia giornaliera di tutta la pool ricorsivamente con retention di 2 settimane. Se stai per fare operazioni potenzialmente distruttive su un dataset, puoi anche farne uno manualmente e mantenerlo finché non sei sicuro sia tutto ok.
Sono la tutela migliore per

  • recuperare file cancellati o sovrascritti
  • attacchi ransomware (già, è successo a chi esponeva il Nas su internet senza criterio…)
  • backup locale rapido →

→ Da soli non sono un vero e proprio backup, ma uno snapshot replicato (esempio su un altro sistema o su pool esterna) è una copia identica che oltre ai file si porta dietro tutto il filesystem (permessi, … )

Un’ altro strumento molto utile (e che ammetto anch’io sto usando in realtà da poco) sono i checkpoint della pool: lo snapshot agisce a livello di dataset e non può salvarti da situazioni tipo

  • sbagli il target di una replicazione con sovrascrittura
  • aggiungi un vdev e te ne penti
  • fai l upgrade della pool e te ne penti
  • lanci comandi ZFS sbagliati (c è stato un caso in cui un utente ha copiato incollato un comando da chat gpt e ha praticamente cancellato ricorsivamente tutto /mnt :smile: )

Se non hai problemi con la lettura in inglese ti giro qualche risorsa, in italiano purtroppo non ho nulla a portata di mano

1 Like

Purtroppo riapplicando i permessi ricorsivamente al dataset in questione non ho risolto.

Ho provato un chmod -R 755 applicato al mio tank (Giuseppe), ma ottengo un “Operation not permitted” per tutti i file presenti.

Nel frattempo, quindi, sto usando di nuovo l’FTP per fare il backup dell’altra cartella. Una delle due non visibile, quella più grande, proverò a cancellarla sempre tramite FTP, mentre la più piccola vorrei lasciarla per eventuali ulteriori prove per capire come risolvere.

Sì, comunque girami pure le risorse in inglese, grazie!

Strano sinceramente, hai provato anche a rispuntare apply user e group? l output del comando precedente è rimasto invariato? Se provi a spuntare i permessi anche al gruppo di fianco a dx?

Per le risorse:
snapshot

checkpoint

Già che ci sono :smile: so per certo che dalla prossima release (che non sarà a brevissimo) non ci sarà più il supporto a Core perché sta diventando parecchio oneroso per il mantainer… Ma dà un’occhiata anche al multi report, per avere un backup settimanale della configurazione, schedulare gli smart test in maniera più agile, e monitorare sempre via mail lo stato dei dischi (e se ci investi qualche minuto nel settarli, li vedi anche virtualmente come sono posizionati nel case :smile: )

Sì, anche dando i permessi al gruppo, gli output dei comandi precedenti restano invariati. Quando vado per confermare il cambio di permessi, la GUI rimane così:

Grazie per le guide, intanto!

Per quanto riguarda questa cosa qui, invece: ho visto che nelle opzioni di update c’è anche la possibilità di passare a una di queste versioni:

Mi consiglieresti la migrazione? Sarebbe una operazione “indolore” per le configurazioni attualmente presenti sul NAS, oppure dovrei poi rimetterci mano dopo l’aggiornamento?

Prova con l ACL manager (io usavo quella modalità), aggiungi Giuseppe e utenti con full control - flag ricorsivo e riprova. Il fatto che la GUI si pianti così mi fa pensare a qualche problema che probabilmente varrebbe la pena acchiappare nell audit

Io ho fatto il sidegrade poco più di un anno fa e non è stata proprio un’esperienza indolore, nemmeno però così drammatica. Dipende molto da cosa stai effettivamente facendo con Core adesso:

  • dubito tu stia usando jails (app), quelle vanno migrate manualmente
  • dubito tu abbia dataset GELI encrypted, in caso vanno replicati-decriptati prima
  • dubito tu stia usando comandi specifici per BSD, in caso vanno adattati per funzionare su Linux (Scale ha base Debian)
  • cronjob, replication task, snapshot task, certificati, … Tutto viene migrato bene
  • le pool, share, … Tutto viene migrato bene
  • dubito (e spero :smile: ) tu faccia spindown dei dischi, ma con scale 25.10 è necessario fare una patch specifica per continuare a farlo (e va ripetuta ad ogni update)
  • i job (e tutta la GUI) relativa agli smart test in scale 25.10 è stata rimossa
  • in Scale non si usa più (motivi di sicurezza) l account root, c è una miniguida da seguire per creare un account con gli stessi poteri

Il cambio di train da GUI te lo sconsiglio proprio, non ricordo a che condizioni va a buon fine. Se hai poche impostazioni, io farei un backup della configurazione di Core → installazione pulita di Scale → carichi la configurazione → ti crei l utente admin e disattivi root come consigliato.
In caso di problemi basta non fare upgrade delle pool e puoi tornare a Core senza grossi problemi

EDIT: ho ritrovato link alla guida

1 Like

Ok, via ACL manager il salvataggio è andato a buon fine ed ora le cartella sono nuovamente sfogliabili via SMB! Grazie!

Allora, fondamentalmente non uso nulla di ciò che hai elencato (nemmeno lo spindown dei dischi!), mentre ho qualche dubbio in merito alla parentesi “app” che hai usato relativamente a jails: non credo di sapere cosa intendi.

:100:

Quando sarà allora il sidegrade sarà poco problematico :smile: puoi anche procedere così
→ salvi la configurazione (per scrupolo ) → esporti le pool in Core → installazione pulita di Scale → importi le pool e risetti tutto manualmente (utenti, share, permessi…).
Così ci metti un po’ più di tempo ma sei sicuro di non avere eventuali strascichi.

Forse non stai usando le jail, nemmeno i plugin?

1 Like

Questa la mia situazione in quanto a plugins e jails! Se c’è altro che devo controllare, dimmi pure.

Ok, credo sia nelle mie corde! :laughing: Ma quando sarà, mi sa che ci risentiremo!!! :sweat_smile:

1 Like

Mi sento di dirti che non dovresti avere grossi problemi. Non usi jails (sono dei mini container isolati con la propria rete/file system dove puoi farci girare applicazioni, sono specifici di freebsd quindi non esistono in Scale), né plugin (sono jail preconfezionate, e pure male :face_with_crossed_out_eyes:). Per me quella fu la parte più delicata avendone a suo tempo una quindicina :smile:
Allo stesso modo ti direi che finché non vuoi esplorare il mondo “app” o non viene fuori qualche breakdown, non c è fretta nel sidegrade, c è ancora una bella fetta di utenti su Core, nonostante sia EOL… Il suo lavoro come file storage Nas lo fa ancora bene. E se decidi comunque di farlo, non usare l ultimissima versione di Scale, prendi sempre l’ultima segnata come uso generale e non early adopter (tipo adesso sarebbe quella che uso io, la 25.04, mentre c è già la 25.10 disponibile).

Mi pare di averti detto tutto :smile: se avessi ancora dubbi chiedi pure!

1 Like

@oxyde grazie veramente di tutto! Ci sentiamo per la migrazione, allora, quando sarà! :wink:

1 Like

E rieccomi qui! Buon Natale a tutti, prima cosa! :evergreen_tree: :evergreen_tree: :evergreen_tree:

Dopo l’ultima peripezia con le cartelle sparite, ho seguito i consigli di @oxyde e finalmente queste sono tornate visibili ed utilizzabili tramite SMB.

Ho però ora notato che i due utenti (ognuno con relativo pool) possono vedere i contenuti dell’altro utente.

Prima accadeva ciò: se sfogliavo l’IP del NAS, vedevo le due cartelle con il nome dei due utenti, ma potevo sfogliare effettivamente sfogliare solo il contenuto della cartella che riportava il nome dell’utente con cui avevo sfogliato l’IP (Es.: Utente Giuseppe, aggiunto all’IP in SMB per sfogliare il NAS = mi permetteva di vedere solo i files e le cartelle presenti in Giuseppe; se provavo a sfogliare quelle dell’altro utente, mi veniva restituito l’avviso da Windows che non avevo i permessi per farlo).

Ora invece, entro con utente Giuseppe e posso vedere anche i dati della cartella che riporta il nome dell’altro utente! All’inizio della creazione degli utenti e dei pools, feci questa distinzione che mi permetteva di avere indipendenza, ma ora vorrei cortesemente un aiuto nel ripristinare la situazione di prima, considerando l’accaduto appena trascorso.

Grazie in anticipo per la risposta!

Buon Natale :smile:
Riguardando i post precedenti credo di aver trovato il problema, colpa mia :sweat_smile: :

togli i permessi al gruppo e dovrebbe tornare effettivamente come prima

1 Like

Editando le impostazioni dell’utente (solo il mio, però), l’ho trovato così. Togliendo i flag a “Group” e “Other”, è tornato tutto come prima!

Sull’altro utente, però, non c’era nulla. C’è da dire che non avevo fatto la prova ad entrare con il mio e sfogliare l’altro, ma solo al contrario.

Grazie ancora! :blush:

1 Like