On 7/27/26 9:06 AM, Marcelo Laia wrote:
The motivation here is a little different. I'm trying to understand how
Linux behaves when the target filesystem unexpectedly disappears and how
to prevent applications from silently falling back to the underlying
filesystem.
My observation has been if the target filesystem unexpectedly disappears
in use, without proper unmounting, it throws write errors rather than
trying to write to the underlying filesystem. Now if it managed to
cleanly unmount in the process of disappearing, it might try writing to
the underlying filesystem.
Another related angle is when an automatically mounted filesystem does
not mount at boot and an automatic file backup program starts.
I just ran into this recently on my workstation. I forgot I'd been
working on the networking and came back and booted it: no networking. So
I fixed that and continued working. At this point my nfs file server
listed in /etc/fstab was not mounted. This machine is due soon for a
larger ssd, by the way. It is 95% filled.
I noticed my Deja-dup automatic daily backup was started and gave it no
farther thought.
Soon the application I was running started showing errors: "No more
space on device" Some quick investigation showed that
/home/user/share/backups/workstation-1/ was automatically created by
deja-dup and started a massive first-time backup.
In this situation, the fix was relatively easy. I stopped deja-dup,
confirmed the nfs share is actually not mounted, then deleted everything
out of /home/user/share
Next I did (this must be done WITHOUT the share mounted, otherwise you
are trying to change ownership of the mounted directory):
sudo chown root:root /home/user/share
This makes local directory 'share' root owned and nobody else has
read/write permissions for it. Since deja-dup is not running as root, it
now stops with 'backup failed' if the share directory did not mount.
