fstab lost my edits - when is fstab overwritten?

[RoGeorge]

The samba hdd (manually added a few months ago in /etc/fstab), is no longer there.  fstab looks like it was overwritten with a brand new one, though its date is 2021-12-01, and I know for sure I've added in fstab the samba hdd in 2022 (and used it a few times).

- When or what usually overwrites the fstab?
- Is this normal to happen or is it a malware?

[brucehoult]

It would probably help to know what distro you are using. Some regard everything in /etc (and other system locations) as fine to just overwrite every time there is an update.

[RoGeorge]

If so, how is one supposed to preserve a customized fstab?  Is there any other local fstab that will append the /etc/fstab or take precedence, so to preserve the edits?

Kubuntu 22.04, I've removed this info by mistake while editing the OP, sorry.

[sokoloff]

Be wary if you used the -y flag in the update. I usually get asked the question something like "/etc/foobar has been changed locally and is updated in the new distro. What do you want to do? [d]isplay changes, Shell to fix it, [y]es take the new one, or [n]o keep the old".

Exact options uncertain, but similar to that, and if I passed in the -y flag, I wouldn't be surprised if that caused the overwrite [because I'd have kind of told it to].

[shapirus]

/etc/fstab isn't normally managed by any dpkg package and it's not (re)generated by any services that I know of.

No idea what it could be, but sudo chattr +i /etc/fstab will set the immutability attribute and protect it from any modification. When something tries to modify it, this operation will fail, which will normally result in a respective message being produced on the screen or in the logs, and that will allow you to find the culprit if you watch for it.

sudo chattr -i /etc/fstab will remove the immutable attribute.

[RoGeorge]

Until will find out what happened, will keep /etc/fstab as immutable anyway. 
Thank you for the workaround.

[sokoloff]

Here's the output snippet I was recalling from a do-release-upgrade from 20.02 LTS to 22.04.2 LTS.

It was crontab, not fstab that it was prompting me for. I manually edited /etc/fstab before the dist-upgrade and it did not get touched in the upgrade (see history below).

Code: [Select]

Setting up cron (3.0pl1-137ubuntu3) ...

Configuration file '/etc/crontab'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** crontab (Y/I/N/O/D/Z) [default=N] ?


Code: [Select]

root@test-fstab:~# history
    1  apt install emacs
    2  emacs /etc/fstab
    3  apt update
    4  apt upgrade
    5  pwd
    6  ls
    7  history
    8  cat /etc/fstab
    9  do-release-upgrade
   10 cat /etc/fstab
   11 history

[bitwelder]

As a helper (I don't dare to call it a 'backup'), you could install and configure 'etckeeper', which automatically stores in VCS every detected change for configuration files in /etc.

[shapirus]

As a helper (I don't dare to call it a 'backup'), you could install and configure 'etckeeper', which automatically stores in VCS every detected change for configuration files in /etc.

And for actual backups, I'd recommend Amanda. It's not the easiest to get started, and, originating from the ancient past, it's built for tape storage, but this can be easily emulated on normal hard drives and, most importantly, it works well for standalone systems and doesn't require external databases (unlike e.g. Bacula which does) to run.
It's a proper versioned backup solution allowing to back up and restore file systems of any size, and it works with localhost as well as remote hosts.

[JohanH]

Many services have moved their user editable config files into a folder conf.d inside their settings directory in etc. This prevents user customizations from being overwritten by upgrades.

Fstab is different, though. It's old and becoming deprecated. It doesn't work well in modern systems. Instead, you can create a systemd unit to mount your special disks, such as smb or nfs shares. Google for systemd.automount.

[shapirus]

Fstab is different, though. It's old and becoming deprecated.

Source?

It doesn't work well in modern systems.

What does it mean exactly? It works today just as well as it did 20 years ago.

Instead, you can create a systemd unit to mount your special disks, such as smb or nfs shares. Google for systemd.automount.

This goes against the unix philosophy. There is no reason to bloat systemd any further than it already is.

But yes, it can be used to replace /etc/fstab, which is a good way of making system configuration more obscure and reduce long-term reliability and maintainability, which is the actual goal of systemd, if we were to deduce its goal from its design.

[JohanH]

This goes against the unix philosophy. There is no reason to bloat systemd any further than it already is.

Every f**ing time. 

You are more than 12 years late.

I work partly as a system administrator and I've never heard anyone talking about that they practice "Unix philosophy". Then I've used Linux on desktop since 2008 or thereabouts, on servers before that. It's only a concept that stupid trolls on the Internet have bickered about when they don't like something new, such as actual technical improvements.

Stop these deranging stupidities now and move on and get on improving the world. Backwards thinking is good for nothing.

[shapirus]

Stop these deranging stupidities now and move on and get on improving the world. Backwards thinking is good for nothing.

To each his own, I guess. Not following the KISS and "a tool must do one thing and do it well" approaches is not forbidden, nor is shooting yourself in the foot forbidden.

Still, it would be interesting to hear why exactly /etc/fstab is becoming deprecated and how exactly its suitability for modern systems differ from that of the systems 20 years ago.

[RoGeorge]

JohanH, you have been mind-conditioned to react violently to whatever goes against the propaganda that was poured at you.  The only stupid thing would be to assume any Unix-like computer has systemd.

I know personally at least two admins who mentioned Unix philosophy many times, and that was way before systemd.  Unix philosophy is not some recent invention to annoy systemd fanboys.  By admins I mean dudes in charge with the fiber optic backbone of Romania, or with the network of a major bank name with hundreds of locations across Romania.  So what you say that admins don't talk about Unix philosophy is not true.

By the way there was always a place for local config files, no need to reinvent that.  I won't say where, for the tease.    BSD also has such files that never get overwritten.  Even I know that, and I'm not an admin.

for actual backups, I'd recommend Amanda

For backup I use borg https://www.borgbackup.org/ but my upset was not about how to restore the fstab.  I was upset/worried for it was overwritten and I don't recall when that happen.  That's against Unix philosophy and traditions. 

[sokoloff]

Before we get too wound up about "why", I think it's worth examining "whether" it's being deprecated.

I don't see any evidence to support that in Ubuntu 22 LTS nor 22.10 documentation: https://manpages.ubuntu.com/manpages/kinetic/man5/fstab.5.html

If other distros choose to go down that path, that's certainly OK (we should encourage a lot of experimentation and the flourishing of different ideas; the ones that are tested to be better will tend to win and we're all better for it).

[shapirus]

Before we get too wound up about "why", I think it's worth examining "whether" it's being deprecated.

That's actually what I wanted to ask, yes. Poor choice of a word.

[JohanH]

Yes, sorry, I'm tired. I just tried to help. But it's so tiring that just because I _mentioned_ systemd, somebody has to drag up this tiring debate again. All is not black and white. Just because I mention there is another way to do it, doesn't mean that _I_ am hating everything else than that!

I myself have used fstab since I began learning Linux/Unix more than a quarter century ago and I'm still using it when needed. Now I mentioned a relatively easy alternative to mount network shares in another way, and you can see the reaction above. I don't have anything more to say. Thanks.

[shapirus]

Yes, sorry, I'm tired. I just tried to help. But it's so tiring that just because I _mentioned_ systemd, somebody has to drag up this tiring debate again.

Nope, it wasn't because you mentioned systemd. It was 1) because you mentioned deprecation of /etc/fstab, of which I have never  heard of and was genuinely interested why you said it was becoming deprecated; and 2) because using a separate tool, in this case systemd, means solving a problem which doesn't exist, needlessly increasing entropy and creating additional points of failure.

The unix philosophy exists regardless of systemd, and, as was mentioned above, existed long before systemd, and it is applicable in any context. Systemd is just a very good example of a design generally considered inappropriate in the Unix world for two reasons: 1) it tries to do many independent things in a single monstrous application; 2) it tries to reinvent many wheels and does it poorly. This is exactly what is to be avoided in an easy to maintain failure-proof system.

[JohanH]

The unix philosophy exists regardless of systemd, and, as was mentioned above, existed long before systemd, and it is applicable in any context. Systemd is just a very good example of a design generally considered inappropriate in the Unix world for two reasons: 1) it tries to do many independent things in a single monstrous application; 2) it tries to reinvent many wheels and does it poorly. This is exactly what is to be avoided in an easy to maintain failure-proof system.

I've heard this for more than 10 years now and the world is still standing (well for the most part), fortunately there are fewer of the "believers" touting these arguments nowadays. At the end of the day, you use technical tools that are available. Or you take the initiative and create new ones (trolling in forums doesn't help). I'm sure we had the same debate when automobiles threatened the existence of horses. People cling to something common and comfortable that they know, and the new and unknown appears threatening and uncomfortable. Typical of humanity. But we all learn through change. Good luck!

[shapirus]

I've heard this for more than 10 years now and the world is still standing (well for the most part), fortunately there are fewer of the "believers" touting these arguments nowadays.

Zero belief. It's purely practical considerations and 20+ years of experience of building reliable systems.

[JohanH]

Systemd is just a very good example of a design generally considered inappropriate in the Unix world for two reasons: 1) it tries to do many independent things in a single monstrous application; 2) it tries to reinvent many wheels and does it poorly. This is exactly what is to be avoided in an easy to maintain failure-proof system.

Both points are myths and wrong.

On my system there are 58 individual systemd binaries, and if you build it with all options there are even more.

Code: [Select]

$ rpm -qa | grep systemd | xargs rpm -ql | grep 'bin/' | wc -l
58

That it reinvents stuff poorly I have seen nothing about. All systems I've used have had zero problems with systemd. So your definition of "poorly" comes from your own experience that doesn't necessarily apply to everyone else. Or maybe it's only hearsay. Besides, it has invented a lot of stuff that didn't exist before.

Now this all is from my narrow viewpoint. I don't understand the big controversy (really, after 12 years?) and frankly, I don't care. I'm happy we have free and open source software and there are a lot of things that require much more energy and resources than bickering about ancient init systems.

[alm]

If you want a more traditional Unix-like environment, then I'd recommend the open-source BSD variants. Particularly OpenBSD and NetBSD are very hesitant to make big changes.

Mainstream Linux distributions will keep moving on, whether you like it or not.