i permessi in fstab si cambiano da soli!

[laba]

scrivo qui per chiedere aiuto per un problema strano e fastidioso.
Succede che, senza che io abbia fatto nulla, i permessi in scrittura suuna partizione fat32 si cambino da soli, pur essendo l'fstab corretto.
Ciò accade da 4-5 giorni, e me ne accorgo perchè emule si chiude da solo e poi non si apre dicendo che non ho i permessi giusti sulla partizione.
La soluzione è smontare e rimontare a mano la partizione.
Avete idea di cosa possa causare questo problema?
Ah, uso Ubuntu Edgy.

[liviux]

Non ho una risposta, ma a me succede la stessa cosa su Kubuntu Dapper cercando di fare un backup su un disco esterno formattato in fat32. Scrive fino ad un certo punto, poi incappa in qualche errore e da quel momento in poi mi dice che non può scrivere perchè il disco è di sola lettura. Lo strano è che il comando mount continua a mostrare il disco come "rw". Smontando e rimontando ritorna scrivibile.

[bort_83]

bisogna vedere con dmesg se il kernel lascia qualche messaggio...

[laba]

non so se può essere d'aiuto a spiegare il fatto...ho tolto il commento alle linee inserite in fase di installazione da ubuntu per quel che riguarda le partizioni fat32 che poi mi ero montato per i fatti mei dopo, e ho ovviamente commenatao le righe inserite da me.
ecco il mio fstab:

# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
# /dev/sda3
UUID=47af711c-bb73-43ae-841a-f3d2146dbac6 / jfs defaults,errors=remount-ro 0 $
# /dev/sda4
UUID=049cb158-5a6d-4dc2-9548-6b0e0c98db44 /home ext3 defaults 0 2
# /dev/hdb2
#UUID=E0F0F24BF0F22784 /media/backup ntfs defaults,nls=utf8,umask=007,gid=46 0 1
# /dev/sda5
UUID=0F63-1A00 /media/dati vfat defaults,utf8,umask=000 0 1
# /dev/hdb1
UUID=43BE-2E8A /media/linux vfat defaults,utf8,umask=000 0 1
/dev/sda1
UUID=E65CC1AC5CC177B7 /media/winsis ntfs defaults,nls=utf8,umask=007,gid=46 0 1
# /dev/sda6
#UUID=EE30B68430B652F7 /media/winswap ntfs defaults,nls=utf8,umask=007,gid=46 0 1
# /dev/sda7
UUID=1ed0739a-1cb3-4290-9998-96590afad31d none swap sw 0 0
/dev/hdc /media/cdrom0 udf,iso9660 user,noauto 0 0
/dev/ /media/floppy0 auto rw,user,noauto 0 0
#/dev/hdb1 /media/linux vfat defaults,rw,umask=000 0 0
/dev/hdb2 /media/backup vfat defaults,umask=000,rw 0 0
#/dev/sda5 /media/dati vfat defaults,user,rw,umask=000 0 0
#/dev/sda1 /media/winsis ntfs defaults,umask=000 0 0

la sola cosa che cambia è che io non avevo inserito la codifica dei caratteri dei nomi dei file, oltre all'id che buntu assegna ai dischi.
Il bello però è che per due mesi ha funzionato senza fare una piega!

[liviux]

Interessante. Cambia anche che Ubuntu NON ti ha messo l'opzione "rw".
Forse ci avviciniamo a capirci qualcosa. Su un filesystem fat32 non sono supportate molte caratteristiche dei FS più evoluti, come i permessi, proprietari, gruppi, nomi Unicode ecc. L'opzione "errors=remount-ro" che hai sulla partizione jfs sda3, anche se in sè non c'entra con fat32, mi fa sospettare che il comportamento in caso di errori di scrittura su una partizione vfat sia proprio quello che su jfs è dichiarato esplicitamente: smontare e rimontare in sola lettura. E l'errore potrebbe essere legato all'impossibilità di codificare un nome di file contenente caratteri non ASCII. Ti pare plausibile?

[laba]

ubuntu non aveva messo rw,ma io nei miei l'ho aggiunto. Nel fstab che ho postato l'avevo tolto, visto che comunque non dava vantaggi.
ora che me lo fai notare penso che potrebbe essere come dici tu: usando emule spesso i nomi dei file hanno codifiche strane quando si scarica qualche cosa, per cui potrebbe essere che ubuntu lo vede come un errore di filesystem e smonta e rimonta.

E' però da ieri che con l'fstab che ho non si prsenta più il problema della mancata scrittura, solo si è chiuso emule da solo durante la notte, ma forse è dovuto al fatto che è una versione cvs..

[laba]

Rieccomi qua!
Ieri si è ripresentato il problema, stavolta ho dato un bel "dmesg" e ho visto che effettivamente ci sono una serie di errori sulla partizione fat32. Ecco qui un estratto:

FAT: Filesystem panic (dev hdb1)
[17184223.552000] clusters badly computed (302 != 286)

.....
.....



questo vuol dire che ci sono errori sui settori del disco, esatto? Ora provo a vedere di trovare un frontend per SMART, e capire come provare a fare un ripristino. Spero che non sia il disco che sta per lasciarmi!


Questo invece non lo capisco: mi dice che il masterizzatore è aperto, quando è da due giorni chiuso..

[17221995.940000] Buffer I/O error on device hdc, logical block 0
[17221995.944000] hdc: tray open
[17221995.944000] end_request: I/O error, dev hdc, sector 4
[17221995.944000] Buffer I/O error on device hdc, logical block 1


Un'ultima cosa a propositodi ACPI. Vedete qualcosa di strano in questo output? Perché alle volte quando torno dopo un'assenza di qualche ora per farlo uscire dallo standby non basta muovere il mouse, ma devo premere un tasto sulla tastiera, e anche quando rientro il mouse non funziona, e l'unico modo è riavviare, perchè il sistema è diventato instabile, e risponde con un ritardo mostruoso..
thanks! :cool:
[17179609.948000] ACPI: Power Button (FF) [PWRF]
[17179609.948000] ACPI: Power Button (CM) [PWRB]
[17179610.064000] ibm_acpi: ec object not found
[17179610.088000] pcc_acpi: loading...
[17179610.428000] powernow: PowerNOW! Technology present. Can scale: frequency and voltage.
[17179610.436000] powernow: Trying ACPI perflib
[17179610.436000] powernow: ACPI perflib can not be used in this platform
[17179610.436000] powernow: ACPI and legacy methods failed
[17179610.436000] powernow: See http://www.codemonkey.org.uk/projects/cpufreq/powernow-k7.shtml