Mount NAS da fstab impossibile con riga di mount valida dopo un crash per disco /home pieno

3 risposte [Ultimo messaggio]
Ritratto di renedrive
renedrive
(Geek)
Offline
Geek
Iscritto: 25/01/2008
Messaggi: 63

Ciao a tutti.
Ho subito un crash anomalo al riempimento della partizione /home che ha causato diverse anomalie.
Ho una discussione aperta su questa generica anomalia a questa discussione
Home riempita ha causato perdita di parte della configurazione KDE ed altro
In questa discussione però voglio trattare la sola questione del problema del mount del NAS perché è molto urgente.
Tratto il suddetto NAS come il secondo disco più importante dopo quello interno dei vari computer che uso.
Tutto passa dal NAS, ogni lavoro ed ogni svago.
Ho quindi molte attività bloccate ed altre ostacolate da questa anomalia.
L'anomalia si presenta solo e soltanto sulla macchina OpenSUSE che è il mio computer principale.
Su due portatili diversi e diverse macchine virtuali tutto funziona perfettamente con la medesima riga di fstab,la medesima configurazione di mount.
Userò come confronto con la macchina principale OpenSUSE una macchina virtuale che questa ospita e che funziona correttamente che usa Linux Mint.
Le due macchine sono configurate esattamente alla stessa maniera, stessa riga di mount, stesso file di configurazione utente e password, nello stesso percorso e con gli stessi permessi, verificato più volte.
L'anomalia è che la macchina OpenSUSE non accede al contenuto del NAS con gli stessi permessi della macchina Mint anche se configurata in modo identico.
Per la macchina Mint i file del NAS risultano correttamente montati con
proprietario
utente = renedrive
gruppo = disk
e permessi
proprietario = leggibile e scrivibile
gruppo = leggibile e scrivibile
altri = vietato
Per la macchina OpenSUSE, la mia macchina principale, che ospita la macchina Mint di confronto
proprietario
utente = 1001
gruppo = nobody
e permessi
proprietario = leggibile e scrivibile
gruppo = leggibile e scrivibile
altri = nessun accesso
Quindi.
Nella macchina Mint ho pieno accesso ai file e cartelle, come dovrebbe essere.
Nella macchina OpenSUSE l'accesso ai file quindi dovrebbe risultare impossibile, nemmeno la visualizzazione,
In realtà su quest'ultima ci sono diversi comportamenti a seconda dei file.
E' interdetto il taglia, l'incolla, il duplica, il rinomina, quindi ogni forma di scrittura, è consentito solo il copia.
Posso visualizzare file video e ascoltare file audio.
Sembra che per molti file sia possibile l'accesso in sola lettura se sono stati copiati sul NAS prima dell'anomalia, ma quelli copiati dopo la data dell'anomalia, quindi copiati dalla macchina Mint, perché l'unica tra le due che lo può fare, siano interdetti completamente all'accesso anche in sola lettura.
Nelle proprietà dei permessi tra i file copiati prima e dopo l'anomalia non c'è differenza, le proprietà sono identiche e tutte esattamente uguali all'esempio sopra riportato.
Si deduce quindi che la direttiva che prevede "nessun accesso" per "altri" funziona solo dal momento dell'anomalia in poi, con i file copiati sul NAS dopo quell'evento e dalla macchina Mint, mentre per i file precedenti la direttiva "nessun accesso" non funzioni e si comportino come "sola lettura"
NOTA AGGIUNTIVA: Ho verificato ora, mentre scrivevo, anche l'unico file video copiato dopo l'anomalia risulta illeggibile, mentre tutti gli altri li posso vedere.
Le due configurazioni di fstab
La macchina Mint
//192.168.1.54/media                       /media/NAS_NG    cifs  credentials=/home/renedrive/.smbcredentials,vers=1.0,iocharset=utf8,file_mode=0777,dir_mode=0777,_netdev,x-systemd.automount,auto,nofail,gid=disk,uid=renedrive,sec=ntlm,rw  0        0
La macchina OpenSUSE
//192.168.1.54/media                       /media/NAS_NG_01    cifs  credentials=/home/renedrive/.smbcredentials,vers=1.0,iocharset=utf8,file_mode=0777,dir_mode=0777,_netdev,x-systemd.automount,auto,nofail,gid=disk,uid=renedrive,sec=ntlm,rw  0  0
sono identiche (non è la stessa riga copiata due volte, ma le effettive due righe prese dai due computer ora, in effetti l'unica differenza è il nome cartella del percorso di mount).
Il file .smbcredentials è presente in tutti e due i computer, ha gli stessi permessi configurati allo stesso modo, di proprietà dell'utente renedrive in tutti e due i casi.
Non trovo particolari errori o segnalazioni nel dmesg della macchina OpenSUSE cercando i termini mount, cifs, NAS, l'indirizzo IP.

Vi viene in mente qualcosa?
Avete qualche verifica da farmi fare?

PS: una aggiunta all'ultimo minuto.
Una idea che mi è venuta per una "pezza" che forse potrebbe funzionare mentre cerco di capire e sistemare.
Provo ad aggiungere il mio utente al gruppo "nobody" questo dovrebbe darmi pieno accesso mentre cerco di capire.
Ho fatto la modifica ma potrò riavviare solo alla fine di una elaborazione video in corso, credo nel pomeriggio.
Poi aggiornerò con un post.
E' comunque una situazione non risolutiva, voglio tornare al funzionamento iniziale di OpenSUSE con il mount fatto con utente corretto e utente proprietario dei file corretto.
A dopo per questo aggiornamento.

AMD Phenom 9650 Quad-Core - openSUSE Leap 15.4 (x86_64) - Linux 5.14.21-xx-default - KDE 5.90.0 - Radeon X800 XL

Ritratto di renedrive
renedrive
(Geek)
Offline
Geek
Iscritto: 25/01/2008
Messaggi: 63

Allora, un paio di test in più ed alcune informazioni aggiuntive.

Mettere il mio utente nel gruppo nobody non ha sortito quasi nessun risultato.
L'unica possibilità che solo su alcuni file è comparsa come possibile è "duplica qui" tutte le altre che prevedono scrittura sono rimaste disattive.
Soluzione appartenenza al gruppo nobody quindi bocciata.

Nel frattempo mi sono accorto che la cartella di mount ha cambiato proprietario e permessi.
La cartella di mount ha;
proprietario
utente = 1001
gruppo = nobody
e permessi
proprietario = leggibile e scrivibile
gruppo = leggibile e scrivibile
altri = leggibile e scrivibile

Originariamente, prima del crash, la cartella aveva permessi
proprietario
utente = renedrive
gruppo = disk
e permessi
proprietario = leggibile e scrivibile
gruppo = leggibile e scrivibile
altri = vietato
lo so perché l'avevo creata io così configurando il mount.
1)
Ho quindi tentato di cancellarla con utente root.
Permesso negato.
2)
L'ho quindi cancellata avviando il computer da un disco di avvio di Puppy.
Appena riavviato il computer la cartella è stata ricreata di nuovo con proprietario 1001 dal sistema.
3)
Ho proceduto a commentare la riga di mount nel fstab.
Riavviato il pc da cd di Puppy
Cancellata la directory
Riavviato OpenSUSE
La cartella, per fortuna, non era stata ricreata.
Ho quindi creato la cartella di nuovo manualmente
Gli ho fornito i seguenti permessi
proprietario
utente = renedrive
gruppo = disk
e permessi
proprietario = leggibile e scrivibile
gruppo = leggibile e scrivibile
altri = vietato
cioè esattamente gli originari e che con "altri = vietato" dovevano evitare la modifica..
Ho tolto il commento alla riga fstab del mount del NAS
Ho riavviato
La cartella risultava di nuovo con
proprietario
utente = 1001
gruppo = nobody
e permessi
proprietario = leggibile e scrivibile
gruppo = leggibile e scrivibile
altri = leggibile e scrivibile
Nulla è cambiato nell'operatività che risulta interdetta come prima.

Una cosa ho capito.
Il sistema è in grado di modificare i permessi della cartella anche se questa era configurata di proposito con "altri" = "vietato"
Ora quindi devo "solo" capire che cosa nel sistema cambia i permessi della cartella anche senza averne teoricamente la possibilità.
Non sarebbe male anche capire perché root non ha modo di interagire con quella cartella e sono costretto ad usare una live per farlo.

Vi aggiorno dopo altre prove, tenendo presente che in questi giorni ho parecchio, parecchio da fare e per ora non ho più tempo da perdere per cercare di risolvere.
Ci risentiremo con aggiornamenti se ne avrò appena ne avrò.

In attesa di vostre idee che sarebbero ben accette se ne sapete qualcosa.
Grazie

AMD Phenom 9650 Quad-Core - openSUSE Leap 15.4 (x86_64) - Linux 5.14.21-xx-default - KDE 5.90.0 - Radeon X800 XL

Ritratto di renedrive
renedrive
(Geek)
Offline
Geek
Iscritto: 25/01/2008
Messaggi: 63

In un tentativo, ultimamente fallito, di installare la 15.4, troppo presto perché non ci sono ancora disponibili i repository "secondari", sono poi, per risolvere, tornato alla 15.3, con una installazione da zero, formattando la partizione di sistema.
Questo ha risolto il problema di questa richiesta, con la stessa riga di fstab, identica a prima, ora il tutto funziona perfettamente e di nuovo sono in grado non solo di leggere ma anche scrivere o modificare i dati.
I permessi visibili nei file del NAS sono tornati di proprietà del mio utente come utente di mount e attribuiti giustamente al gruppo disk, come era sempre stato prima dell'anomalia.
Il problema quindi in effetti non è risolto, ma aggirato.
Grazie comunque a chiunque abbia tentato di comprendere il problema.

AMD Phenom 9650 Quad-Core - openSUSE Leap 15.4 (x86_64) - Linux 5.14.21-xx-default - KDE 5.90.0 - Radeon X800 XL

Ritratto di renedrive
renedrive
(Geek)
Offline
Geek
Iscritto: 25/01/2008
Messaggi: 63

renedrive ha scritto:

... tornato alla 15.3, con una installazione da zero, formattando la partizione di sistema.
Questo ha risolto il problema di questa richiesta, con la stessa riga di fstab, ...


Smentisco il precedente commento.
E' successo che per poco, qualche giorno, tutto sembrava funzionare ma poi la situazione è tornata ad essere la stessa, nessun permesso di scrittura.
La cosa si fa quindi ancora più strana, non ho idea di cosa causi tale anomalia, se qualche aggiornamento.

Nel frattempo sono passato effettivamente a OpenSUSE 15.4, riformattando completamente, anche la home, che mi portavo dietro intatta da anni, quindi una installazione completamente pulita e l'anomalia del mount del NAS è esattamente la stessa con la stessa configurazione in fstab.
Passare alla 15.4 mi ha dato problemi più gravi, risolti con l'apertura di un bug report, ma ora l'altra anomalia più urgente è questa del NAS.
Cercherò di capirne l'origine e risolvere.

AMD Phenom 9650 Quad-Core - openSUSE Leap 15.4 (x86_64) - Linux 5.14.21-xx-default - KDE 5.90.0 - Radeon X800 XL