Re: Preventing writes to the underlying directory when a mounted filesystem disappears

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.