The Solaris group is a forum where peers share technical expertise, solve problems, and discuss issues related to the Solaris operating system, including OS-related malfunctions, security issues, and network performance.

Regarding Fsck in Solaris

I have a db Server in which I got I/O error. So when I rebooted the server it come's up fine with no errors.But After Some time it's again throwing the I/O error During accessing the files.So I rebooted the Server in Single user mode and did Fsck on 4 Slices (Like s4,s5,s6,s7) (fsck -Fy ufs -o b=32 </dev/rdsk/c0t1d0s5> ) it's thrown some errors and fsck fixed as I have given -y option .So after rebooting the server it came up fine .The Output for df -h Showing same used space and everything correct but when I entered in to the mountpoints of those slices data is not there.The Data Went in to Lost+found dir.So Tried to Enter in to Lost+found Dir but it's Saying Permission Denied.So How to get back the data.

Popular White Paper On This Topic

Lost+found is a mixed blessing - your files may be in there but identifying them can be troublesome sometimes. However, you are right - the permissions will not allow a normal user to read or move them. It is just a permissions issue, judicious use of root privilege and chmod to alter the privileges should allow you access.

I assume you are familiar with chmod to change permissions on files. You could run it recursively over everything in lost+found although unless you have MANY files in there I would tend to prefer to treat files one at a time.

I saw your mail and i want to share with you same which i faced
kindly do this

1. unmunt /s4 /s5 /s6 /s7,
rmove the directory examle if it is mount with /syed

#mount dev/dsk/c0t1d0s5 /syed .remov syed directory & create one directort
abc and try to mount it as
#mount dev/dsk/c0t1d0s5 /abc i hardly belive that your problem will
solve Insha Alah
then mount your directory as it was

I'm sure you know this by now, but for others who may be reading this.
Once fsck has found errors, *do not* use the filesystem until you know
why, and have a recovery plan.

Often, a filesystem is in a decent state when the fsck errors show up.
However, start writing on the filesystem, and the errors grow. The thing
to do is backup immediately. Reads on a filesystem will (usually) not
harm it. Though it may be slow as bad blocks are retried.

Of course, if you do have a good set of backups, then you only need to
backup from the date of the last backup. But it is often easier to just
back the whole filesystem up, make a new filesystems (replacing any
marginal disks in the process) and then use the previous backup to
take care of anything that was damaged.

Judicious use of fsck -b (use an alternate superblock) can be a lifesaver.
But it will not solve all problems, and other than block #32, it is not
trivial to know where the other superblocks are.

To avoid this problem in the future, perform periodic fscks from time to
time as you can (during maintenance windows, for example.) Or better
yet, upgrade to ZFS if you can.

--->Edited /root/list.dir to make it as script to show the list of files in
each directory with directory name. Here is a snippet of my script.*
set -v**
ls -l \#10104455
ls -l \#10104531
ls -l \#10104536
.....................*