Unix administration - FAT32 weirdness

This is Interesting: Free IT Magazines  
Home > Archive > Unix administration > November 2006 > FAT32 weirdness





You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

Author FAT32 weirdness
Jim Showalter

2006-11-15, 7:29 pm

Greetings!

For about five days last week, I suddenly began having a problem some
times when Mozilla Thunderbird tried to download mail to a FAT32 drive
/e. Every few times, it would fail, reporting that the file system was
read-only. And sure enough, entering "touch /e/t" gave: "touch: cannot
touch `/e/t': Read-only file system"

Note: /e is mounted at boot by user jim, the mount point and every file
in the file system belong to jim. This had worked flawlessly for
five months.

The first time this happened, I examined everything I thought relevant.
All was as it should be in /etc/fstab, with the output of mount and the
directory/file permissions were unchanged!

There are more details available in the thread "Thunderbird making
FAT32 readonly file system" in the "netscape.public.mozilla.mail-news"
newsgroup where I was trying to get help with this problem last week.

The problem has now disappeared just as mysteriously as it began,
leaving me really curious, especially about the following.

When this would occur, I found I could replicate the problem simply by
issuing the following commands as a normal user:

jim@atlas:~> touch /e/t
jim@atlas:~> chmod -w /e/t
jim@atlas:~> rm /e/t
rm: cannot remove `/e/t': Read-only file system
jim@atlas:~>

But following an unmount/mount of /e by root, the same sequence (again
as a normal user) would produce:

rm: remove write-protected regular empty file `/e/t'? y
jim@atlas:~>

What does this behavior suggest?

Cheers!
droid
--
I know what I believe. I will continue to articulate what I believe and
what I believe - I believe what I believe is right. --George W. Bush
* Now that's articulate! *
Jim Showalter

2006-11-16, 1:17 pm

Sorry - I just realized, my question and it's lead-up are misleading.
It should read:

During the time this was occurring, when the file system was Ok, I
could replicate the problem simply by issuing the following commands
as a normal user:

jim@atlas:~> touch /e/t
jim@atlas:~> chmod -w /e/t
jim@atlas:~> rm /e/t
rm: cannot remove `/e/t': Read-only file system
jim@atlas:~>

But since the problem has disappeared, the same sequence produces:

rm: remove write-protected regular empty file `/e/t'? y
jim@atlas:~>

How could making one file read only have caused the entire file system
to become read only?
--
Doug Freyburger

2006-11-20, 1:18 pm

Jim Showalter wrote:
>
> During the time this was occurring, when the file system was Ok, I
> could replicate the problem simply by issuing the following commands
> as a normal user:
>
> jim@atlas:~> touch /e/t
> jim@atlas:~> chmod -w /e/t
> jim@atlas:~> rm /e/t
> rm: cannot remove `/e/t': Read-only file system
> jim@atlas:~>
>
> But since the problem has disappeared, the same sequence produces:
>
> rm: remove write-protected regular empty file `/e/t'? y
> jim@atlas:~>
>
> How could making one file read only have caused the entire file system
> to become read only?


The usual reason for going read-only is a hardware failure and the
filesystem layer making the entire filesystem R/O. Then a
remount to turn it back to R/W. Note that the error message does
include "file system".

You did double check that you could create files in other directories
or with another name, right?

Jim Showalter

2006-11-21, 1:30 am

Doug Freyburger wrote:
> Jim Showalter wrote:
>
> The usual reason for going read-only is a hardware failure and the
> filesystem layer making the entire filesystem R/O. Then a
> remount to turn it back to R/W. Note that the error message does
> include "file system".


You are right. I found since that the disk had some errors, so I
moved everything to a new disk. I consider myself very lucky, as I
didn't even need to use my daily backups and didn't lose so much as
one file!

>
> You did double check that you could create files in other directories
> or with another name, right?
>


I'm not sure of your meaning here. The entire file system on the drive
mounted on /e would become read-only. And if I can't create a file by
one name, why might another succeed?

Cheers!
droid
--
I know what I believe. I will continue to articulate what I believe and
what I believe - I believe what I believe is right. --George W. Bush
* Now that's articulate! *
Doug Freyburger

2006-11-21, 7:21 pm

Jim Showalter wrote:
> Doug Freyburger wrote:
>
>
> You are right. I found since that the disk had some errors, so I
> moved everything to a new disk. I consider myself very lucky, as I
> didn't even need to use my daily backups and didn't lose so much as
> one file!


No data lost - Always a good outcome.

>
> I'm not sure of your meaning here. The entire file system on the drive
> mounted on /e would become read-only. And if I can't create a file by
> one name, why might another succeed?


Every so often you can "touch fs/a" but not "touch fs/b". There are
other
events that can trigger the RO f/s message -

The next thing to try might have been to go over your NFS automounter
tables for errors. You can trigger a read-only filesystem error using
the
automounter if you get creative enough, but hardware failures are the
most common cause so checking automounter is the second path to
try. No need to go there this time.

Sponsored Links






Free braindumps | Software forum | Database administration forum

Copyright 2003 - 2008 webservertalk.com