Have you deleted any directories, etc...?
It would appear as though the services do not have permissions to write to the area indicated in link.conf.
No, we did not delete anything.
OK ... we need to check the permissions, etc... of some things thing.
What are the contents of /usr/tideway/etc/link.conf? You can find this with:
$ cat /usr/tideway/etc/link.conf
The tideway user needs to be able to read/write to all of the locations listed in that file. If any permissions have been changed on those directories, or the links don't exist, it may cause the error you're seeing.
By default, the following directories should all exist and be have tideway:tideway ownerships and 755 permissions:
And the following symlinks should exist (they should be owned by tideway:tideway but will have 777 permissions):
/usr/tideway/var/backup -> /usr/tideway/var/localdisk/backup
/usr/tideway/var/tideway.db/data -> /usr/tideway/var/localdisk/tideway.db/data
/usr/tideway/var/tideway.db/logs -> /usr/tideway/var/localdisk/tideway.db/logs
OK, do the appropriate symbolic links exists in /usr/tideway/var and /usr/tideway/var/tideway.db?
As the tideway user run:
$ touch /mnt/addm/db_data/data/testfile
$ touch /mnt/addm/db_data/backup/testfile
I suspect that something in those trees does not allow the tideway user to write to those locations.
Do both /mnt/addm/db_data/data/testfile and /mnt/addm/db_data/backup/testfile fail to create?
Make sure the mount point owned by tideway:tideway and has write permission.
This will tell you the mount point:
$ cat /etc/fstab
You will see something like:
/dev/sdb1 /mnt/addm ext3 defaults 0 0
A listing of that directory will then show the ownerships and permissions:
$ ls -ld /mnt/addm
That should be owned by tideway and be writeable.
That's, umm, odd!
What do the mount, fdisk & df commands show?
$ sudo /bin/mount
$ sudo /sbin/fdisk -l
$ df -h
The fdisk option is the lowercase letter l.
OK - there are a few issues here.
The /mnt/addm/db_data directory appears to have been deleted. /mnt/ is also full. Then there is the fact there is no second partition on /dev/sdb. It appears as though the underlying filesystem has been changed outside of the disk utils tool. Those explain the issues you're seeing.
Attempt to unmount the bad mount directory. This may error and I'm not entirely sure about how the system got into this state. As the root user:
# umount -f /dev/sdb2
I would suggest deleting the VMware tools tarball from the /mnt directory. Then recreate /mnt/addm/db_data and make sure it's owned tideway:tideway. As the root user:
# rm -f /mnt/VMwareTools-*.tar.gz
# mkdir -p /mnt/addm/db_data
# chown tideway:tideway /mnt/addm/db_data
Then the UUID for /dev/sdb1 needs to be determined:
$ blkid /dev/sdb1
Output will look something like this:
$ blkid /dev/sdb1
/dev/sdb1: UUID="5b3334d5-f793-488b-b8d1-c32d15142b17" TYPE="ext4"
Edit the /etc/fstab file to set the correct UUID for the /mnt/addm/db_data. For example, using the above UUID:
UUID=5b3334d5-f793-488b-b8d1-c32d15142b17 /mnt/addm/db_data ext4 defaults 1 2
Then mount the partition to see if this works. As the root user:
# mount -a
If the command is successful - something appears under /mnt/addm/db_data - then reboot. If not, post the error here.
Riiiggggghhhhhttttt ..... Andrew Waters just spotted that you have mounted the VMware Tools installer on /mnt. Assuming you were attempting to install VMware tools and ran: mount -o loop /dev/cdrom /mnt rather than a sensible path like /mnt/cdrom?
This doesn't explain where /dev/sdb2 has gone.
Thanks for the help.
Before go with steps suggested by you to resolve the issue., i'hv reboot the machine and now we are able to login on Appliance.(feeling lucky )
But still i am thinking that reboot is not solution.
Will perform the step's and let you know the result.
The reboot would have un-mounted the offending VMwareTools mount.
The steps are not necessary if all is good with the world now
The only concern I would have is why /mnt/addm/db_data was mounted on /dev/sdb2 when all of this is happening.
If the output of the mount command shows that /mnt/addm/db_data is mounted on /dev/sdb1 then everything is probably as it should be.