[mount] Ability to temporarily mount a filesystem without altering /etc/fstab

[darkdragon-001]

SUMMARY

Migration of ansible/ansible#48134:

Ability to perform temporary mounts without altering /etc/fstab. Currently anything done with the mount module needs to manipulate /etc/fstab.

Additional parameter is needed to perform temporary mounts, such as with an ISO image that would be unmounted later in a play. Currently this can't be done with the mount module, as altering the /etc/fstab is required. Maybe call this additional parameter modify_fstab of type bool. Currently the only way to achieve this is via the command module using direct mount/unmount commands.

ISSUE TYPE

• Feature Idea

COMPONENT NAME

mount, fstab

ADDITIONAL INFORMATION

To mount an ISO image temporarily for pulling in data, but not make an entry in /etc/fstab.

- name: Mount an ISO Temporarily
  mount:
    src: /path/to/my/iso.iso
    path: /path/to/mount/my/iso
    fstype: iso9660
    opts: ro
    modify_fstab: no
    state: mounted

- name: Unmount an ISO
  mount:
    path: /path/to/unmount/my/iso
    modify_fstab: no
    state: unmounted

[chrystalis]

An additional use case discussed in the issues and PRs opened previously (2571, 19820, 48134) over the last 5 years, and one I am currently facing, is the need to temporarily mount a filesystem that is already configured in fstab. Currently the mounted state requires that 'src' be provided, which is reasonable if updating fstab is required, but should be optional if a valid entry already exists in fstab.

For example, if I need to add filesystems to a server and migrate existing content without changing the directory layout, I might have a playbook that creates the filesystems and mountpoints in their final desired state but does not actually mount them yet. Then I might have a playbook to mount them in a temporary location, migrate existing content to the new filesystems, and then unmount the temporaries and remount them in their new, permanent location.

[NathanDotTo]

See https://github.com/ansible-collections/ansible.posix/issues/107.

[quidame]

It would probably be clearer to separate configuration and running state, and split them into two module parameters, the same way it is done for service or systemd modules, with state to describe the wanted running state of the service (started/stopped/restarted), and enabled to describe the wanted persistent state of the service: enabled at boot or not.

Mounts could be managed the same way, with (at least one of these params required):

    state: mounted/unmounted/remounted
    enabled: yes/no  # configured in fstab, or not

For me, the current choices for the state option aren't obvious: the differences between present, absent, mounted and unmounted need I read the docs very often. present is not the opposite of absent, and unmounted is not the opposite of mounted. And with these four states, we are even not able to just get an active mount without modifying fstab.

So I agree that the module needs some boolean param to deal with fstab, but I think enabled would be more consistent than modify_fstab, and the state option should be refactored in the same time (to not make complicated things such as "enabled is ignored when state=absent or state=mounted (or sate=present too, maybe)").

[sjpb]

Don't really see why the previous issue was closed, looked like there was good discussion there. The ansible core team's argument that it means the "mount" module has too many options doesn't seem like a very convincing argument given modules like ansible.builtin.file.

[quidame]

A part of the trouble with the state option of this module, is that two of its values describe (or lead to) the same state, but depend on the initial state.

• When starting from state=absent (that is the opposite of state=mounted), with state=present, fstab is configured but the mount is not actually mounted.
• When starting from state=mounted, with state=unmounted, the mount is unmounted but fstab is left configured, that is very close to the previous result.

But when doing the same from state=absent to state=unmounted, or from state=mounted to state=present, nothing happens, that means in that cases state=unmounted and state=present lead to opposite results (since absent is the opposite of mounted, and nothing has changed).

This makes clear for me that there are two things to control separately: the current mount state, without worrying about fstab contents (as does state=unmounted); and the fstab contents, without worrying about current mount state (as does state=present). Maybe another state (state=active ?) would be sufficient to cover the need of mounting a device without modifying fstab, but state values are already confusing enough in my opinion.

On the other hand, moving to split an option into two options by keeping its name in the new set may be confusing too, and needs probably more work (deprecation step, etc). Anyway, it seems to be a better target. That would migrate this way:

• old state=present --> new enabled=yes + state=None
• old state=mounted --> new enabled=yes + state=mounted
• old state=unmounted --> new enabled=None + state=unmounted
• old state=absent --> new enabled=no + state=unmounted (or keep state=absent for mountpoint removal ?)

other ideas ?

[chrystalis]

I'd be fine with quidame's suggestion if it is the easiest non-breaking solution.

For consistency with service/systemd, however, I would personally prefer to have the end goal of:

• state=present meaning "mounted", state=absent meaning "unmounted"
• state=remounted dropped in favor of a force (or perhaps force_mount) option
• enabled=yes meaning "present in fstab", enabled=no meaning "not present in fstab"

Something like this:

• enabled: [ yes | no ] - Requires src, path, fstype. Ensures fstab is configured appropriately for the requested mount.
• force: [ yes | no ] - Requires state.
  • If state=present, equivalent to current state=remounted behavior
  • If state=absent, equivalent to umount -f <path>
• state: [ present | absent ] - Requires path. No longer a required option if enabled is defined.
  • If present, and src and fstype are NOT defined, equivalent to mount <path> (which will only succeed if the entry is already in fstab), otherwise equivalent to mount [-o opts] -t <fstype> <src> <path>.
  • If absent, equivalent to umount <path>.
  • Deprecate mounted: now equivalent to present - but continue current behavior of also updating fstab unless also enabled=no
  • Deprecate unmounted: now equivalent to absent - but continue current behavior of also updating fstab unless also enabled=yes
  • Deprecate remounted: recommend using force for this instead - but continue current behavior of attempting remount

I admit I have not looked at the code and do not know if my suggestions would be onerous to implement. However, this would also cover my additional use case of ensuring that a previously configured mountpoint is actually mounted, without needing to know all of its details (i.e. src and fstab) if they are already present in fstab.

If adding the additional force option introduces too much complexity, then leaving state=remounted as a valid (non-deprecated) option is OK.

[SckyzO]

Because Dev team couldn't update this feature, I use another workaround

- name: "Mount ISO CentOS"
  mount:
    path: /mnt
    src: "/tmp/centos.iso"
    fstype: iso9660
    opts: loop
    state: mounted
    fstab: /tmp/tmp.fstab

- name: "Mount ISO CentOS"
  mount:
    path: /mnt
    src: "/tmp/centos.iso"
    fstype: iso9660
    opts: loop
    state: unmounted
    fstab: /tmp/tmp.fstab

Use a fake/temp fstab file.

[sjpb]

Hah, that's neat. So once done with the mount, is it ok to simply unmount and delete tmp.fstab?

[SckyzO]

Hah, that's neat. So once done with the mount, is it ok to simply unmount and delete tmp.fstab?

Yes :)

[olastor]

If anyone needs another workaround for simply mounting a device:

  - name: Create mountpoint for new root partition
    file:
      path: /newroot
      state: directory

  - name: Mount new root partition
    shell: |
      (lsblk | grep /newroot) || mount /dev/mapper/cryptroot /newroot

[MrSuicideParrot]

@saito-hideki Is there any ETA for #267 being merged? It looks like it has been approved in June of this year.

[NeodymiumFerBore]

Hello @MrSuicideParrot , I'm the author of the PR you mentioned, as an external collaborator. Thank you for your interest! I tagged Hideki and Akasurde, who were the approvers for this PR. I will try to bring it back to life. Some changes occurred since it was approved, so I may have some work to do before it can be merged.

[TimZaman]

TLDR; this is now fixed as state: ephemeral! 🎉