I've thought about something similar.

But decided it was a better option to make back-ups via backintime and then back those up via rsync to a recovered WD-MBLive running on OpenWRT.

Worked quite well till it didn't and stopped using it.
Fortunately, files were not lost but I now have to see how to avoid it happening again.

Not at all, thanks for your input.

Best,

A.

All are mounted through fstab in /home/$USER/local/ ...

I find it easier for me to put them there rather than in the system, /media or /mnt.

Also the permissions are different to yours because they are all (except other OS's) mounted at boot.

I use a few symlinks for my home folder from those data partitions like, documents, bin, build, music, pictures...videos...

A collection of backups there too that I need to be careful not to change the perms on those.

Anyway, I'm a bit chatty today... :-) I hope this helps someone.

... updatedb ran when the filesystem was not mounted ...

Right.
Which is why the files ended up hiding when updatedb ran with the usually unmounted FS and showed up again if/when when I happened to run updatedb whith the FS mounted.

Hmm ...
I have come to think that Murphy works in mysterious ways ...  8^°'

Thanks for your input.

Best,

A.

But the locate result came up repeatedly, seems that it could find the hidden files.

From man locate
locate reads one or more databases prepared by updatedb(8) and writes file names matching at least one of the PATTERNs to standard output, one per line.

So if updatedb ran when the filesystem was not mounted it would find the "hidden" files and put them into the database. So running locate repeatedly would always show them, until the next updatedb run.

I see.
That could have easily happened.

Yes.
But the locate result came up repeatedly, seems that it could find the hidden files.
Which is the reason I set out to see where they were.

Thanks for your input.
Best,

A.

To fix it, you could get fancy with overlay mounts so that DATA did not get covered, but moving it out as already suggested is a much better idea.

'locate' shows you what it found the last time updatedb ran, which might be different from what files exist now. updatedb usually runs once a day.

Thank you for the prompt reply.
Much appreciated.

I see.

Hmm ...

So fstab was not working properly?

Done.

I then copied everything back to where it should have been ie: /media/storage/DATA and after checking everything was in place, deleted /media/storage2.

I was in a very ugly mood for the longest while when I "lost" all those files, so many thanks for this.

But why did this happen?
It was (undoubtedly) of my own doing but I cannot imagine what I did.

I would like to avoid going through this again.

Thanks in advance.

Best,

A.

To recover I suggest:
df -k /media/storage
If the filesystem is mounted there unmount it, and re-check with df -k /media/storage to make sure it's not mounted now.
As root:
cd /media
ls -al
Make sure there is not a storage2 dir already!
mv storage storage2
mkdir storage
Then storage2 will contain all the recovered data and the process of mounting the filesystem when needed should still work.

I've had to get at data buried under a mount point *without* unmounting the filesystem. But I would not recommend doing that unless you fully understand the process (NFS doesn't cross mountpoints, so mounting the root filesystem via NFS lets you get there. But it's a tricky process.)

I have come across something I am at odds with and don't understand.

I have a drive where I store data and has this fstab entry:

# -------------------------------------------------------------------------------------
#
# not automatically mounted - root only
# storage repository in 300Gb SAS s/n JHX71JDC
# was LABEL=storage  /media  ext4  defaults,auto  0  2
UUID=74649bbb-7fb9-46bc-990a-d3d96dd92dd9 /media/storage ext4 nouser,noauto  0  2
#
# -------------------------------------------------------------------------------------

Early on, I went from defaults,auto  0  2 to nouser,noauto  0  2 so that is would not be mounted at all times, only when I needed to access it.

The thing is that if I want to mount it, I get the usual "Authenticate" pop-up asking for my password and once entered, I see what I think is the content.
ie:
/media/storage -> 9 folders + 9 files
Total count: 8817 files
Size on disk: 14.2Gib

Some time ago, I lost a great deal of files to a misconfigured rsync ...   ... or so I thought.

Today I accidentally stumbled (via locate) on one of those files, stored in /media/storage/DATA, one of the folders I thought was long gone along with its content.

So I fired up PCMan, had a look but it was nowhere to be seen.
ie: it was not one of the 9 folders under /media/storage.

I entered /media/storage/DATA in the PCMan address bar only to get a pop-up which informed me that it was not a valid directory.

On a hunch, I unmounted the /media/storage volume in PCMan, entered /media/storage/DATA in the address bar and there it was.

Not only that: all the files I thought I had lost were there.

I think there is some sort of permission problem at hand, no idea how this happened.

When I select all the files ie: /media/storage -> 9 folders + 9 files and select properties, the Owner and Group fields are blank.
In Access Control, view content is blank and Change content reads Only owner.

In /media/storage/DATA the Owner and Group fields read root (grayed out).
In Access Control, view content is reads Anyone Change content reads Only owner.
 
I don't understand what is going on.
I always thought that if fstab read nouser,noauto that was it.

ie: access did not depend on the ownership of the files it contained, just on being admin/root.

What am I missing?
Most importantly, how can I fix this?

Thanks in advance.

Best,

A.