# null /etc/mtab

## Gentree

I often use df -h and recently it have failing unless I give it an explicit device name. 

I have just found out the reason is that /etc/mtab is an empty file:

```
ls -ail /etc/mtab

912418 srwxrwxrwx 1 root users 0 Jul  1 08:39 /etc/mtab
```

```
grep -v rootfs /proc/mounts grep -v rootfs /proc/mounts > /etc/mtab

bash: /etc/mtab: No such device or address

```

Those perms look suspicious, is this an indication of a hack ?

TIA Gentree.

----------

## DONAHUE

ln -s /proc/self/mounts /etc/mtab

----------

## Gentree

yes, thanks, I've already done that.

My question was about how it got to be in the state it was with odd permissions, zero content, users group access etc. 

The error on the grep command as root was odd too. It looks a bit like a simlink with a missing or unprintable name.

----------

## DONAHUE

fx8150 ~ # ls -ail /etc/mtab

827556 lrwxrwxrwx 1 root root 19 Jul  8 21:48 /etc/mtab -> ../proc/self/mounts

fx8150 ~ # grep -v rootfs /proc/mounts grep -v rootfs /proc/mounts > /etc/mtab 

grep: input file ‘/proc/mounts’ is also the output

grep: grep: No such file or directory

grep: rootfs: No such file or directory

grep: input file ‘/proc/mounts’ is also the output

greps on separate lines:

fx8150 ~ # grep -v rootfs /proc/mounts

PARTUUID=89bc9633-fbc9-4a90-8a67-e058cb655d95 / reiserfs rw,nodev,noatime,notail 0 0

devtmpfs /dev devtmpfs rw,relatime,size=8149404k,nr_inodes=2037351,mode=755 0 0

sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0

proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0

tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0

devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620 0 0

tmpfs /run tmpfs rw,nosuid,nodev,mode=755 0 0

tmpfs /sys/fs/cgroup tmpfs ro,nosuid,nodev,noexec,mode=755 0 0

cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd 0 0

efivarfs /sys/firmware/efi/efivars efivarfs rw,nosuid,nodev,noexec,relatime 0 0

cgroup /sys/fs/cgroup/cpu cgroup rw,nosuid,nodev,noexec,relatime,cpu 0 0

systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=22,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0

configfs /sys/kernel/config configfs rw,relatime 0 0

debugfs /sys/kernel/debug debugfs rw,relatime 0 0

hugetlbfs /dev/hugepages hugetlbfs rw,relatime 0 0

/dev/sdd5 /usr/src reiserfs rw,noatime,notail 0 0

/dev/sdd10 /mnt/backup ext4 rw,nosuid,nodev,noexec,relatime,stripe=4,data=ordered 0 0

/dev/sdd8 /usr/share reiserfs rw,noatime,notail 0 0

/dev/sdd3 /usr/portage reiserfs rw,noatime,notail 0 0

/dev/sdd9 /home reiserfs rw,noatime,notail 0 0

/dev/sdd7 /tmp reiserfs rw,noatime,notail 0 0

/dev/sdd4 /var/tmp reiserfs rw,noatime,notail 0 0

/dev/sdd6 /var/log reiserfs rw,noatime,notail 0 0

/dev/sdd1 /root reiserfs rw,noatime,notail 0 0

tmpfs /run/user/0 tmpfs rw,nosuid,nodev,relatime,size=1636556k,mode=700 0 0

fx8150 ~ # grep -v rootfs /proc/mounts > /etc/mtab 

grep: input file ‘/proc/mounts’ is also the output

----------

## Gentree

of course, if you symlink /etc/mtab to something then try to grep it onto the same target, source is same as dest. 

Having found the problem I've fixed it with the symlink.

I still have the same question that I started with: how did this come about and what are the dodgy looking permissions about. 

I have just found an old ( 1st July ) copy of /etc/mtab in lost+found directory. I had disk getting unreliable and the mount points in this file date from the old configuration. This may match when the problem started. 

The permissions I showed also look like a symlink but ls does not show it as a symlink. 

Could this be a bug in the way ext4 repaired the FS ?!

----------

## DONAHUE

http://www.linuxnix.com/2010/02/file-types-in-linux.html

Something made /etc/mtab into a socket file open to others, group, owner. No good idea what the something was.

commands socket and socat (probably others)  create sockets.

----------

