Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I am trying to copy a virtual box image inside /opt folder in RHEL 5.6. I am logged in as the root and I strangely see that I am not able to write anything into /opt folder. I checked the permissions from other machines in the lab and see that the permissions are set correctly. However, in the /etc/fstab file in all the remaining machines (where everything is correct and working fine), I see the below entry.

LABEL = /home1 /opt ext3 defaults 1 2

In the faulty machine where /opt directory is not writable, I see the /etc/fstab file entry as,

LABEL = /home /opt ext3 defaults 1 2

I am quite new to system administration and I believe it has to do something with the improper mounting of the file system as read only. I checked the dmesg for any errors but was not able to understand it. I think I have to remount the /opt with the proper settings. But I don't want to do anything in the lab to disturb the current setup. I just wanted to know if my understanding is correct and, is it the missing "1" in /etc/fstab file causing the /opt to be read only?

EDIT:

After I run the mount command,

The output from the faulty machine,

/dev/sda2 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/sda5 on /opt type ext3 (rw)
/dev/sda1 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
XXXserver.XXX.XXX:/opt/vbox_image on /opt/vbox_image type nfs (rw,addr=192.168.1.10)
nfsd on /proc/fs/nfsd type nfsd (rw)

The output from the correct machine

/dev/sda2 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/sda5 on /opt type ext3 (rw)
/dev/sda1 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
ascentserver.uta.edu:/opt/vbox_image on /opt/vbox_image type nfs (rw,addr=192.168.1.10)
**none on /proc/fs/vmblock/mountPoint type vmblock (rw)**
nfsd on /proc/fs/nfsd type nfsd (rw)

EDIT 2:

If I run the command, for i in $( cat /proc/partitions | awk '{ print $4 }' ) ; do e2label /dev/$i ; done, I get the below output. I am not able to debug this output.

e2label: No such file or directory while trying to open /dev/name
Couldn't find valid filesystem superblock.
e2label: Bad magic number in super-block while trying to open /dev/sda
Couldn't find valid filesystem superblock.
/boot1
/1
e2label: Bad magic number in super-block while trying to open /dev/sda3
Couldn't find valid filesystem superblock.
e2label: Attempt to read block from filesystem resulted in short read while trying to open /dev/sda4
Couldn't find valid filesystem superblock.
/home

EDIT 3:

The ls-l command on /opt directory shows I have rwx permission on all the files inside it. However, I tried creating a simple text file and it was not allowing me to create the file.

share|improve this question
    
The 1 looks more like a typo. However /etc/fstab is not what you should consult, since it is a list of how file systems are intended to be mounted. What you need here is a list of actual mounts - either the output of mount or /proc/mounts will give you the actual state of the system. And there you may see the mounted filesystem to be read only. Also check you don't have any hardening in place that could prevent even root from writing into /opt. –  peterph Oct 2 '13 at 22:28
    
It could be that your mounting via filesystem label (home1 being the label of the disk, device, or partition.) Your first step would be to see what the filesystem labels are for a 'good' host and your faulty host. On each, what is the output of # for i in $( cat /proc/partitions | awk '{ print $4 }' ) ; do e2label /dev/$i ; done –  Stephan Oct 2 '13 at 22:37
    
Are we talking about the same /opt for all machines (i.e. a network share)? If not, then it may be that the pathological host has an unclean filesystem on /opt. Especially if you have power cycled it as you were suggesting. The solution may be to unmount it and fsck it. This would definitely disrupt users of this host, though, so you may want to plan some downtime for it if you decide to go this way. –  Joseph R. Oct 2 '13 at 23:06
    
@peterph, I ran the mount command and updated the output of mount command from the faulty machine as well as the correctly working machine. In the correctly working machine, there is one extra entry as, none on /proc/fs/vmblock/mountPoint type vmblock (rw). Otherwise, the output is the same in both the machines. –  Ramesh Oct 2 '13 at 23:07
    
@JosephR, this is a different machine in the lab. It has all the settings exactly as it is for the remaining machines in the network. I was able to use the virtual box image in all of the machines in the network. However, in this machine alone I am getting this weird read only error. I also tried the mount command, but I am not able to debug any useful info from it. –  Ramesh Oct 2 '13 at 23:10

2 Answers 2

Run the command showmount -e XXXserver.XXX.XXX where this is the server serving this NFS mount: /opt/vbox_image.

What's most likely happening is that the server giving you access to this NFS share has the root_squash bit turned on for this NFS exported share. This disallows the root user from remote systems that mount this shared mount, from having the ability to access it.

excerpt from 18.7. The /etc/exports Configuration File

root_squash — Prevents root users connected remotely from having root privileges and assigns them the user ID for the user nfsnobody. This effectively "squashes" the power of the remote root user to the lowest local user, preventing unauthorized alteration of files on the remote server. Alternatively, the no_root_squash option turns off root squashing. To squash every remote user, including root, use the all_squash option. To specify the user and group IDs to use with remote users from a particular host, use the anonuid and anongid options, respectively. In this case, a special user account can be created for remote NFS users to share and specify (anonuid=,anongid=), where is the user ID number and is the group ID number.

share|improve this answer
1  
/opt itself (the one where the OP is facing problems) seems to be a local mount. –  Joseph R. Oct 2 '13 at 23:44
    
@JosephR. - are you sure? Look at this line: XXXserver.XXX.XXX:/opt/vbox_image on /opt/vbox_image –  slm Oct 2 '13 at 23:46
    
Yeah and ls -l command on /opt gives me rwx access. But I was not able to create a text file inside /opt folder and I also checked if I have enough space on my disk using df -h command. –  Ramesh Oct 2 '13 at 23:47
    
@Ramesh - do a df /opt that will tell you where it's coming from. –  slm Oct 2 '13 at 23:48
1  
As I said the permissions don't mean anything if this is a mount. Permissions is one aspect of determining if you have access to a directory, they aren't the only thing. Things like root_squash and SELinux can override this and make it look like you should have access but do not. –  slm Oct 2 '13 at 23:49
up vote 0 down vote accepted

I ran the fsck command as suggested in the chat window. After unmounting the volume and running the fsck command, I got an error as "*bad or duplicate blocks foun*d" and fsck command seemed to fix that issue.

After this step, I checked the access to write under /opt folder and it was also fine. I thought of installing the windows from a .ova file and deleted the older one (This windows7.ova was present under /opt folder and it was one of the files that was giving the duplicate or bad block error). I deleted that image and everything went for a toss. The system suddenly started giving read-only error and when I restarted it was not giving me anything.

I figured may be reinstalling RHEL in the system with new partitions might help and did that. However, I encountered an error at the end saying "Installation failed". But the system was loading fine and I was able to login as the root.

I installed the virtualbox and tried to install Windows 7 again inside the VirtualBox. Again, I got the error saying "The file is corrupted". This time when I googled the error, most of the pages suggested it might be a hard drive issue. So, I heavily suspect this error was caused due to some bad sectors in the hard drive.

Please correct me if am wrong. Thanks everyone for your help.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.