Perché un filesystem montato può creare file ma rifiutare le rinominazioni?

Un filesystem montato può consentire la creazione di file, ma rifiutare le ridenominazioni perché la ridenominazione richiede autorizzazioni separate sulla directory, proprietà, limiti del filesystem, flag e gestione degli handle aperti.

Un montaggio riuscito dimostra solo che il filesystem è collegato, mentre una scrittura riuscita dimostra che il client può creare o modificare almeno un oggetto. La ridenominazione è un’operazione sulla voce di directory che può richiedere autorizzazioni su entrambe le directory di origine e destinazione, diritti di eliminazione, un percorso nello stesso filesystem, un nome di destinazione valido e l’assenza di modalità di condivisione SMB in conflitto o di flag che proteggono il file. Acquisisci l’errore esatto e confronta separatamente creazione, ridenominazione, spostamento ed eliminazione prima di considerare danneggiato il filesystem.

Acquisisci l’errore esatto di ridenominazione prima di modificare le autorizzazioni

Ripeti una ridenominazione dall’host e dal client interessato. Registra il percorso di origine, il percorso di destinazione, l’identità dell’utente, il filesystem, il punto di montaggio, il codice di errore e indica se il nome di destinazione esiste già.

Gli errori della chiamata di sistema Linux rename distinguono i problemi di autorizzazione, i punti di montaggio occupati, gli spostamenti tra dispositivi, i filesystem di sola lettura, le destinazioni non vuote e altre condizioni che possono apparire identiche in un file browser grafico.

Se la creazione di un nuovo file riesce ma la ridenominazione fallisce, conserva questa differenza. Ciò restringe il problema alla sostituzione della voce di directory, alle autorizzazioni di eliminazione, alle regole di denominazione, ai blocchi o a un limite del percorso, anziché al normale accesso in scrittura.

Controlla le autorizzazioni su entrambe le directory principali

Controlla proprietario, bit di modalità, ACL e identità effettiva sulla directory che contiene il vecchio nome e su quella che conterrà il nuovo nome. L’autorizzazione alla ridenominazione dipende soprattutto dalle directory, non dal bit di scrittura del file.

Red Hat spiega che il bit sticky limita la ridenominazione e l’eliminazione nelle directory condivise scrivibili al proprietario del file, al proprietario della directory o a un utente privilegiato, anche quando più utenti possono creare file al loro interno.

Esegui il test con lo stesso utente NAS che riceve l’errore. Il successo dell’amministratore non dimostra che l’account ordinario disponga dei diritti di eliminazione o ridenominazione su entrambe le voci di directory.

Controlla i flag immutable, undeletable e append-only

Controlla i flag del filesystem sul file e sulle directory principali, oltre alle normali autorizzazioni e ACL. Ripristini, strumenti di sicurezza o flussi di conservazione possono mantenere flag non visibili in un elenco di autorizzazioni di base.

Il manuale sulla sicurezza di FreeBSD osserva che il flag immutable impedisce la modifica o l’eliminazione, mentre i flag append-only e undeletable possono anch’essi bloccare le modifiche alla directory necessarie per la ridenominazione.

Rimuovi un flag protettivo solo dopo aver identificato quale criterio o applicazione lo ha impostato. La cancellazione globale dei flag può compromettere i controlli di conservazione, backup o protezione dal ransomware.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

Escludi uno spostamento tra filesystem nascosto all’interno di un unico albero di directory

Risolvi le directory di origine e destinazione fino a identificare ID dei dispositivi, punti di montaggio, bind mount, dataset e percorsi dei container. Due cartelle della stessa condivisione possono comunque appartenere a filesystem montati diversi.

La GNU C Library definisce EXDEV come errore di ridenominazione tra dispositivi. Uno strumento di spostamento di livello superiore può recuperare copiando ed eliminando, mentre un’applicazione che si aspetta una ridenominazione atomica può semplicemente fallire.

Se uno spostamento locale riesce solo copiando l’intero file, l’operazione non era una ridenominazione atomica. Correggi i percorsi temporanei e finali dell’applicazione oppure mantieni entrambe le fasi nello stesso filesystem.

Controlla gli handle aperti e la condivisione SMB per l’eliminazione

Elenca i file aperti e le sessioni SMB per le directory di origine e destinazione. Chiudi visualizzatori, generatori di miniature, editor, scanner multimediali, strumenti antivirus e client di backup uno alla volta.

Microsoft documenta un caso relativo a una cartella di rete in cui un handle aperto della cache delle miniature blocca la ridenominazione, dimostrando perché la possibilità di leggere o creare altri file non elimina una violazione di condivisione sull’oggetto specifico.

Non riavviare l’intero NAS prima di aver conservato le informazioni sugli handle aperti. Un riavvio può liberare il blocco nascondendo quale client o servizio lo ha ricreato.

Confronta le regole di ridenominazione SMB con il nome file del client

Prova un nome semplice composto da caratteri ASCII minuscoli nella stessa directory. Confronta quindi modifiche riguardanti solo le maiuscole, caratteri riservati, punti o spazi finali, normalizzazione Unicode e un nome di destinazione già esistente.

Il modulo di interoperabilità di Samba con macOS offre un’opzione di compatibilità per la ridenominazione POSIX, mostrando che la semantica dei nomi del client e del server può determinare se una ridenominazione della directory viene accettata.

Se fallisce solo un determinato schema di nome file, conserva la mappatura dei nomi originali prima di normalizzarli. Una ridenominazione di massa senza un elenco per il ripristino può danneggiare librerie multimediali, processi di sincronizzazione, collegamenti e backup.

Correggi il livello verificato e verifica ogni operazione

Correggi solo la causa verificata: autorizzazioni sulla directory principale, proprietà dello sticky bit, flag protettivo, percorso nello stesso filesystem, handle aperto o nome file incompatibile. Ripeti il test con l’utente e l’applicazione originali.

L’articolo di ZimaSpace sulle collisioni dei nomi file che differiscono solo per maiuscole e minuscole tratta il caso più specifico e multipiattaforma in cui due nomi diventano equivalenti nella destinazione.

Il problema è risolto quando creazione, chiusura, ridenominazione, spostamento, eliminazione e ricreazione riescono tutti nel percorso previsto dopo la riconnessione e il riavvio. Interrompi le scritture se il filesystem diventa di sola lettura o segnala corruzione o errori di I/O hardware.

Domande frequenti

Perché posso creare un file ma non rinominarlo?

La creazione richiede l’autorizzazione ad aggiungere una voce alla directory, mentre la ridenominazione può richiedere anche i diritti di rimozione sulla vecchia voce, diritti di scrittura ed esecuzione su entrambe le directory principali, regole di denominazione compatibili e l’assenza di flag protettivi o handle in conflitto.

Un errore di ridenominazione EXDEV significa che il filesystem è danneggiato?

No. Di solito significa che origine e destinazione si trovano su filesystem diversi, quindi il kernel non può completare una singola ridenominazione atomica. Uno spostamento tramite copia ed eliminazione potrebbe comunque funzionare.

È possibile rinominare un file aperto?

Molti filesystem POSIX locali lo consentono, ma i client e le applicazioni SMB possono aprire i file senza condivisione per l’eliminazione, causando il rifiuto della ridenominazione da parte del server finché l’handle non viene chiuso.