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

darkdragon-001 · 2020-08-16T10:44:15Z

SUMMARY

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

The text was updated successfully, but these errors were encountered:

chrystalis · 2020-10-26T17:01:14Z

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 · 2020-10-29T11:11:39Z

See #107.

quidame · 2020-11-01T22:23:07Z

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 · 2020-11-25T08:21:31Z

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 · 2020-11-29T02:32:07Z

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 · 2020-11-30T01:19:43Z

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 · 2020-12-10T10:08:15Z

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 · 2020-12-10T11:41:15Z

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

SckyzO · 2020-12-21T01:03:56Z

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

Yes :)

olastor · 2022-05-28T19:21:25Z

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 · 2022-11-19T22:23:15Z

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

NeodymiumFerBore · 2022-11-23T13:59:06Z

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.

Add ephemeral state to mount fs without altering fstab SUMMARY Add ephemeral possible value for state parameter. The ephemeral state allows end-users to mount a volume on a given path, without altering an fstab file or creating a dummy one. There have been debates about splitting this module into an fstab module and a mount module, but nothing has been done in 5 years. This is why I'd like to propose this feature. Downside: the way the posix.mount module handles mount options prevents it to be able to check exactly if the given opts perfectly match the mount options of an already mounted volume. To achieve this, the module would have to be aware of every mount default options, for all platforms. This is why state=ephemeral always return changed=yes. In other terms, a remount will always be triggered if the volume is already mounted, even if the options look to be the same. Using state=unmounted on a volume previously mounted with ephemeral behaves correctly. ISSUE TYPE Feature Pull Request Related issues: ansible/ansible#48134 #84 COMPONENT NAME mount ADDITIONAL INFORMATION Example use case Sometimes it is handy to be able to temporarily mount a volume. I've seen this in couple companies where Ansible is used to generate reports and put it on network shares. However, some admins don't look into mount options such as krb5 and multiuser for SMB shares. Being forced to use fstab-based mounts leads to clear text passwords being stored more or less temporarily on the host filesystem, requiring "manual" deletion (with the hassle of using blocks, rescues, always, etc.). This feature respond to this use case by providing a way to mount a volume without having to alter an fstab file. Description of changes Edit DOCUMENTATION section to add ephemeral state Edit EXAMPLES section to add ephemeral state example Add new function _set_ephemeral_args to use instead of _set_fstab_args when using ephemeral state Add new function _is_same_mount_src to determine if the mounted volume on the destination path has the same source than the one supplied to the module Add new function _get_mount_info to avoid redundant code between functions get_linux_mounts and _is_same_mount_src Modify get_linux_mount to use the new function _get_mount_info. Original behavior is preserved. Integrate ephemeral parameter treatment into mounted treatment, and add if statements to avoid IO from/to fstab Add ephemeral as a possible value for the state parameter in main() Add required_if dependencies for ephemeral state Reviewed-by: None <None> Reviewed-by: Hideki Saito <[email protected]> Reviewed-by: Abhijeet Kasurde <None>

TimZaman · 2023-04-08T22:25:52Z

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

maxamillion added the feature This issue/PR relates to a feature request. label Aug 25, 2020

darkdragon-001 mentioned this issue Jun 5, 2021

[mount] Allow "boot" option on all Linux via "noauto" #28

Closed

This was referenced Sep 12, 2021

Add ephemeral state to mount fs without altering fstab #264

Closed

Add ephemeral state to mount fs without altering fstab #267

Merged

saito-hideki added the has_pr label Nov 29, 2021

saito-hideki linked a pull request Nov 29, 2021 that will close this issue

Add ephemeral state to mount fs without altering fstab #267

Merged

softwarefactory-project-zuul bot closed this as completed in #267 Dec 15, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

darkdragon-001 commented Aug 16, 2020 •

edited

Loading

chrystalis commented Oct 26, 2020 •

edited

Loading

NathanDotTo commented Oct 29, 2020

quidame commented Nov 1, 2020

sjpb commented Nov 25, 2020

quidame commented Nov 29, 2020

chrystalis commented Nov 30, 2020

SckyzO commented Dec 10, 2020 •

edited

Loading

sjpb commented Dec 10, 2020

SckyzO commented Dec 21, 2020

olastor commented May 28, 2022

MrSuicideParrot commented Nov 19, 2022 •

edited

Loading

NeodymiumFerBore commented Nov 23, 2022

TimZaman commented Apr 8, 2023

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

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

Comments

darkdragon-001 commented Aug 16, 2020 • edited Loading

SUMMARY

ISSUE TYPE

COMPONENT NAME

ADDITIONAL INFORMATION

chrystalis commented Oct 26, 2020 • edited Loading

NathanDotTo commented Oct 29, 2020

quidame commented Nov 1, 2020

sjpb commented Nov 25, 2020

quidame commented Nov 29, 2020

chrystalis commented Nov 30, 2020

SckyzO commented Dec 10, 2020 • edited Loading

sjpb commented Dec 10, 2020

SckyzO commented Dec 21, 2020

olastor commented May 28, 2022

MrSuicideParrot commented Nov 19, 2022 • edited Loading

NeodymiumFerBore commented Nov 23, 2022

TimZaman commented Apr 8, 2023

darkdragon-001 commented Aug 16, 2020 •

edited

Loading

chrystalis commented Oct 26, 2020 •

edited

Loading

SckyzO commented Dec 10, 2020 •

edited

Loading

MrSuicideParrot commented Nov 19, 2022 •

edited

Loading