On Sun, 3 Aug 2008, Akemi Yagi wrote:

> On Sun, Aug 3, 2008 at 1:57 PM, Mark Stodola <[log in to unmask]> wrote:
>>
>> Rachid Ayad wrote:
>>>
>>> On Sat, 2 Aug 2008, Akemi Yagi wrote:
>>>
>>>  Hello Akemi, I think there is a prolem with changin permission,
>>> owner,groups in SL: I was doing this all my life with other linux-like
>>> systems and I never had any problem in particular if I was doing from root.
>>> I followed your procedure by unmounting, mounting, and remounting but it
>>> works for few minutes and later my mounted path (HD) looses its rw option
>>> and becomes only read-only. I tried it several times because I checked that
>>> now chown command shows that /scratch is read-only, so I unmouted, mounted,
>>> and remount as you said above, then run "chown" it works for a while(but
>>> before it immediately says read-only) and then messages saying /scratch file
>>> system are read-only. The same thing happened when we tried to let files
>>> from a user seen from another user by running: "chmod -R g+rw directory"
>>> from root but after doing this the second user still do not see the files
>>> even if the two users have the group.
>>>
>>>  Regards, rachid .
>
>> Check your various system logs.  You may have a bad filesystem or failing
>> hard drive.  When the OS detects problems, it has a tendency to auto-remount
>> read-only.

   Yes it was the filesystem: many bad sectors in the HD like:
***********
Error reading block 10289160 (Attempt to read block from filesystem
resulted in short read) while doing inode scan.  Ignore error<y>? yes

Force rewrite<y>? yes
***********

  after fixing them all with fsck, chown command worked well. So it was 
really the auto-mount in read-only state.

  Thank you, Rachid.


>>
>> Cheers,
>> Mark
>
> Yes, that description indicates some problem causing the filesystem to
> go read-only.  Umount the troubled filesystem and try running fsck on
> it.
>
> Akemi
>
> Akemi
>