Hello...

When I try to edit teh crontab with the crontab -e command I get the following:

/tmp/crontab.XXXXz56XMg: Read-only file system...

mount command shows all filesystems as (rw)

The server is redhat 4.7, vanilla install. How do I edit the crontab? Rebooting the server doesn't help and there is adequate space for usage on the server per df -h...

I appreciate your help as I need to change the root crontab as soon as possible. Everything I've seen on the 'Net has been inconclusive or ineffective.

Thanks!

Blaine

Is /tmp mounted from another server? Even when it's mounted rw on the client side, it could be exported as ro.

There may be a filesystem issue. You will see that error sometimes when there is corruption requiring an fsck. You can edit the crontab directly by editing /var/spool/cron/username, but you may need to restart crond.

Also, try to touch /tmp/test or something to see if you can write to /tmp as root.

I get the same filesystem (ro) error when I do a touch or try to restart crond...

Only difference now is that crond is apparently unable to start again as well...

How would I do an fsck on this system?

Thanks!


Blaine

Can you post the output of "df -h" and "df -i" command ?

Also the contents of /etc/fstab..

Yeah, it pretty much sounds like your filesystem is cooked. If you want to run fsck, first you need to find out which device /tmp resides on. Just type mount and it will show where everything is mounted. It may or may not be on a separate device from /, if you don't see a separate entry for /tmp, then the device is the same as the one used for /. Then, you'll want to boot off a live cd, or installation DVD and go to recovery mode. From there, run fsck -y -C /dev/sda4 or whatever device /tmp resides on. You want to do this off installation media because you do not want to run fsck on a mounted filesystem. So, for hte same reason, do not allow the installation media to attempt to automatically mount your drives (it will usually ask first).

I'd suggest making backups of anything important before you run fsck, because there is always a chance that you'll get some data loss.

Thanks for everyone's help... I'm going to go ahead and scrub this system and reload it from scratch. It's only a VM, so it shouldn't be too tedious. There was nothing of importance on it datawise and reloading the applications resident on the server while tedious, is more doable than trying to continue trouble shooting this mess...

I thank you all and will mark this as resolved...

Blaine

Well, in this case: maybe the file for the virtual file system on the real host is owned by someone else than the user of the VM.