can't umount hard drive
umount /mnt/backups/
umount: /mnt/backups/: not mounted
cat /etc/fstab
/etc/fstab: static file system information.
#
proc /proc proc defaults 0 0
/dev/xvda / ext3 noatime,errors=remount-ro 0 1
/dev/xvdb none swap sw 0 0
cat /etc/mtab
rootfs / rootfs rw 0 0
/dev/root / ext3 rw,noatime,errors=remount-ro,barrier=0,data=writeback 0 0
devtmpfs /dev devtmpfs rw,relatime,size=1019268k,nr_inodes=254817,mode=755 0 0
tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=204092k,mode=755 0 0
tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /run/shm tmpfs rw,nosuid,nodev,noexec,relatime,size=460600k 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
3 Replies
@Nibbler:
Perhaps it is not mounted. In that case /mnt/backups/ is acting like a normal directory. Mount /dev/xvdc at a new mountpoint somewhere else and compare the contents.
Thank you good sir! The contents are not the same. I wonder what /mnt/backups is then since it's the same size as /dev/xvdc.
@blahyawnblah:
Thank you good sir! The contents are not the same. I wonder what /mnt/backups is then since it's the same size as /dev/xvdc.
Something like this could happen if, in the past, a process assumed /dev/xvdc was mounted on /mnt/backups (when it wasn't) and did whatever it does that uses that filesystem. In that case the files were actually going to the parent filesystem instead, but if /dev/xvdc was subsequently mounted, you'd never notice unless you just happened to look at the tree when /dev/xvdc was no longer mounted.
– David