Is it a good idea to add an empty file, say a file called NOT_MOUNTED, into mountpoint directory when the backup storage device is not mounted? Or will this be confusing? Is a symlink better, that becomes broken when the device is unmounted? Is there something else I can do to make it clearer for myself, and for other users, to know the status of a mounted device?
How do I make it obvious in GUI file managers, for example?
You kind of have it backwards. If I saw an empty directory that was usually a mount point, I would assume it wasn't mounted.
If anything, you should put a file in your mounted filesystem to show that it is mounted. Preferably something that indicates what you intend to use the filesystem for, or maybe just the intended contents are enough.
The best way for others to figure out what devices are mounted is the df command. You don't need to make this clear to GUI file managers, they already know. Some of them even have a side panel that lists both mounted and unmounted available filesystems. (Reverse of df, probably the best way to determine if a directory is a mountpoint is the mountpoint command, as mentioned in the other answer.)
Really, this sounds like an XY problem. You're suggesting an unnecessary solution for a problem that you have not mentioned. Why do you think you need to treat a directory special just because it might be a mount point? Why isn't it enough just to see if the directory is empty or contains some things?
Is it a good idea to add an empty file, say a file called NOT_MOUNTED, into mountpoint directory when the backup storage device is not mounted? Or will this be confusing?
No. Leave that directory empty. Otherwise this will be confusing; in fact, multiple tools will refuse to mount something "atop" of a non-empty directory.
Empty directories are empty directories. There's no prior property that makes them mountpoints – not every empty directory is just waiting to become a mountpoint; so this is not a sensible direction to think!
The other direction doesn't work either: a device containing a file system doesn't have a property that says "I need to be mounted under /path/to/mountpoint".
Is a symlink better, that becomes broken when the device is unmounted?
No. If the directory remains there, and the symlink points to that directory, then it will not be broken. If the symlink points to something inside your mounted file system: why not simply check for the presence of that from the start?
Is there something else I can do to make it clearer for myself, and for other users, to know the status of a mounted device?
Check your mounts! Linux has an API to check the mounts visible to every process – you can access that through /proc/self/mountinfo. If your directory is not in there, it's not a mountpoint.
In fact, there's the very handy tool for checking whether a directory is in there: mountpoint. Use it like
mountpoint -q /path/to/directory && do_what_you_do_if_mountpoint Now, if you have a mount system unit (a systemd mount unit), then you can simply check whether that unit is successfully running. In fact, that's a usual way to deal with mounting things for automated backups, anyways: make the backup service depend on that mountpoint. In that case, it can't be started before the mount has been finished.
dumpe2fs -h /dev/vda1 | grep mounted mount and pmount have always served my needs). Is a symlink better, that becomes broken when the device is unmounted?
You don't need a symlink for this, you can use chattr with the i attribute:
A file with the 'i' attribute cannot be modified: it cannot be deleted or renamed, no link can be created to this file
When a directory has this attribute, it’s like a "read-only" mode and you can't modify /mnt/my-storage or its content (unless you use chattr -i /mnt/my-storage).
Example (with a root account):
# Create the mount point $ mkdir /mnt/my-storage # Mark it as read-only $ chattr +i /mnt/my-storage # Try to add a file $ touch /mnt/my-storage/test touch: cannot touch '/mnt/my-storage/test': Operation not permitted Now you can use this directory as a mount point with mount or /etc/fstab, and it will be readable and writable (that will require chown, chmod or setfacl but that’s another subject).
Users will know that a device is not mounted because they will see an empty directory and they won’t be able to add any data in it.
This is also useful for automated tasks like backups, because they will fail instead of storing files on your main filesystem / and filling it up.
One option could be to use permissions to your advantage. If your backup program doesn't run as root, you could:
So any attempts to access it by another user would fail, loudly and obviously. (Depending on what you're doing, this might or might not be desirable - perhaps it might be better for a backup to fail if the external disk is absent, instead of making a backup to a local disk by accident. Perhaps not.) GUIs will also likely display such a folder as inaccessible, and thus make the mount status apparent.
Why not just test whether the device is mounted? E.g.
$ df | grep ^/ /dev/mapper/vg0-root 91732248 17444448 70412904 20% / /dev/mapper/vg0-home 1992552 28176 1843136 2% /home /dev/mapper/vg0-tmp 996780 1220 926748 1% /tmp /dev/mapper/vg1-data 51290592 21479664 27173104 45% /data /dev/mapper/vg0-lib 14373976 7939324 5810108 58% /var/lib $ IsMounted() { df "$1" | awk 'NR == 2 { exit($NF != "'"$1"'") }'; } $ if IsMounted /; then echo yes; else echo no; fi yes $ if IsMounted /mnt; then echo yes; else echo no; fi no $ if IsMounted /tmp; then echo yes; else echo no; fi yes $ if IsMounted /var/tmp; then echo yes; else echo no; fi no 
immutable-mountpoint:-)