Bug 73710

Just mount to different places and have a script set a symlink to which should be active. Defining two different file systems that mount to the same directory is not a supported configuration under systemd.

Yes, I agree that this does not seem to be a bug, but rather a loss of functionality.
Of course there are workarounds, but they are just that: workarounds. A valuable
functionality of mount+fstab has been compromised by adding the intermediate step of
fstab-generator.
I don't know if this interferes with other goals of fstab-generator, but one solution
would be to create the mount unit on-the-fly for units with mount option "noauto".

> A valuable functionality of mount+fstab has been compromised by adding the intermediate step of fstab-generator.

The intention isn't for most users to rely on the generator; it's only there so systemd can consistently manage mounts both native and from fstab. The intention is that folks like you add .mount units for what you need mounted.

> I don't know if this interferes with other goals of fstab-generator, but one solution would be to create the mount unit on-the-fly for units with mount option "noauto".

I'm not sure that would work, but you could change what's in a single .mount unit and daemon-reload systemd to use the altered version. I discourage excessive use of daemon-reload for performance reasons, though.

You could also mount a "file system" in a script like /usr/sbin/mount.mydynamicfs, which would be a mount unit of Type=mydynamicfs. You can put whatever logic you want into the script that performs the mount.

Supporting many mounts on the same mountpoint has been on the TODO list for a while. This case should then be supported too.

So, using fstab with non-unique entries was probably always in the area of "undefined behaviour". Maybe mount itself didn't break, but a lot of other software parsing that file certainly did.

In systemd we explicitly don't support fstabs like this, and will generate the error you saw. THis is unlikely to change, since we name the units automatically after the mount points they refer to, and unit names must be unique.

So, I can certainly see your usecase, but I kinda like the current properties of systemd's mount handling in that the mapping between units and paths is bijective and easily understandable which we'd lose if we wanted to support this usecase.

This issue has come up once before, so we know at least of two people looking for this. However, I am inclined to say that this is probably nothing we will support in systemd, sorry.

I'd recommend to simply use two different mount points for this and manage a symlink as suggested by David Strauss.

Sorry if this answer is a bit disappointing!

(In reply to comment #4)
> Supporting many mounts on the same mountpoint has been on the TODO list for
> a while. This case should then be supported too.

Hmm, it is in the TODO list?

There's an item about properly unmounting a mount point if multiple file systems are mounted on top of each other there, in a stack... But I doubt it makes sense to ever support multiple lines for the same mount point in /etc/fstab fully.

(In reply to comment #6)
> (In reply to comment #4)
> > Supporting many mounts on the same mountpoint has been on the TODO list for
> > a while. This case should then be supported too.
> Hmm, it is in the TODO list?
I understood it this way, but if you say that's not it, then too bad.

(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #4)
> > > Supporting many mounts on the same mountpoint has been on the TODO list for
> > > a while. This case should then be supported too.
> > Hmm, it is in the TODO list?
> I understood it this way, but if you say that's not it, then too bad.

I mean, I am always open for ideas, I just don't see how we could do this without losing the nice property that mount point paths and their unit names are easily translatable forth and back... Do you have an idea how this could work?

(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #6)
> > > (In reply to comment #4)
> > > > Supporting many mounts on the same mountpoint has been on the TODO list for
> > > > a while. This case should then be supported too.
> > > Hmm, it is in the TODO list?
> > I understood it this way, but if you say that's not it, then too bad.
> 
> I mean, I am always open for ideas, I just don't see how we could do this
> without losing the nice property that mount point paths and their unit names
> are easily translatable forth and back... Do you have an idea how this could
> work?
One way would be to have both the source and the target in the unit name.

(In reply to comment #5)
OK, I see your point, but yes, I am a little disappointed. I can live with it, 
anyway :) 
If no modification is expected from systemd, perhaps a warning in the man 
page of fstab should say that valid fstab syntax may be invalid for 
systemd-fstab-generator.

(In reply to Lennart Poettering from comment #5)
> So, using fstab with non-unique entries was probably always in the area of undefined behaviour".

man fstab: "The order of records in fstab is important ..."

This is also imortant for "bind" or "move" mounts or when you mount an image file which lives in another mounted directory.


(In reply to Lennart Poettering from comment #8)
> (In reply to comment #7)
> > (In reply to comment #6)
> > > (In reply to comment #4)
> > > > Supporting many mounts on the same mountpoint has been on the TODO list for
> > > > a while. This case should then be supported too.
> > > Hmm, it is in the TODO list?
> > I understood it this way, but if you say that's not it, then too bad.
> 
> I mean, I am always open for ideas, I just don't see how we could do this
> without losing the nice property that mount point paths and their unit names
> are easily translatable forth and back... Do you have an idea how this could
> work?

Per definition a single line from fstab does not make any sense without the lines before. So maybe just add the line number to unit name ...
The current forth and back name translation does not make any sense.