cloud-init mount option can`t set permissions

This bug was originally filed in Launchpad as LP: #893786

Launchpad details

affected_projects = ['cloud-init (Ubuntu)']
assignee = None
assignee_name = None
date_closed = None
date_created = 2011-11-22T21:46:42.967166+00:00
date_fix_committed = None
date_fix_released = None
id = 893786
importance = wishlist
is_complete = False
lp_url = https://bugs.launchpad.net/cloud-init/+bug/893786
milestone = None
owner = smoser
owner_name = Scott Moser
private = False
status = confirmed
submitter = bjoern-a
submitter_name = Björn Dieding
tags = ['feature']
duplicates = []

Launchpad user Björn Dieding(bjoern-a) wrote on 2011-11-22T21:46:42.967166+00:00

mounts:

[ ephemeral0, /mnt/ephemeral, auto, "defaults" ]
[ swap, none, swap, sw, "0", "0" ]

will create this error

[ec2-user@ip-10-234-85-230 ~]$ mkdir -p /mnt/ephemeral/var.live mkdir: cannot create directory `/mnt/ephemeral/var.live': Permission denied

it looks like a chmod is not implemented

May 09 '23 18:05 ubuntu-server-builder

Launchpad user Serge Hallyn(serge-hallyn) wrote on 2011-11-23T20:56:49.427112+00:00

Thanks for taking the time to report this bug.

I am marking this 'low' priority, per the definition "moderate impact on a non-core application".

May 09 '23 18:05 ubuntu-server-builder

Launchpad user Scott Moser(smoser) wrote on 2011-12-20T01:32:38.942456+00:00

What sort of syntax would you suggest for cloud-config to set permissions on a mount? I'm expecting that in your example you just want to have "ubuntu:ubuntu" as the ownership so that the default user could use it.

May 09 '23 18:05 ubuntu-server-builder

Launchpad user Björn Dieding(bjoern-a) wrote on 2011-12-20T01:46:05.083687+00:00

Yes something like this.

[ ephemeral0, /mnt/ephemeral, auto, "defaults", "ubuntu:ubuntu", 0755 ]

May 09 '23 18:05 ubuntu-server-builder

Launchpad user Scott Moser(smoser) wrote on 2011-12-20T03:35:27+00:00

On Tue, 20 Dec 2011, Björn Dieding wrote:

Yes something like this.

[ ephemeral0, /mnt/ephemeral, auto, "defaults", "ubuntu:ubuntu", 0755 ]

Hm... i suppose we could add a field there, but it wouldn't be ideal. I like the fact that the fields represent exactly what is in /etc/fstab.

But any other solution would require mapping the entry to directory.

May 09 '23 18:05 ubuntu-server-builder

Launchpad user Björn Dieding(bjoern-a) wrote on 2011-12-20T12:24:16.337962+00:00

I do not know... it is up to you...

May 09 '23 18:05 ubuntu-server-builder

Launchpad user Sergii Golovatiuk(sgolovatiuk) wrote on 2013-06-17T12:47:01.968460+00:00

This issue is more serious than you think. For instance, I want to create /tmp as ephemeral. Normally, I assign 1777 permissions to /tmp to allow users to create and delete own files/directories from /tmp. That's very common for very large set of programs. If I set up tmp in cloud-init definition as

[ ephemeral0, /tmp, auto, 'defaults,nobootwait,noatime', '0', '2' ]

it means that permission will be 0755 every time after reboot. It makes cloud-init unusable and requires extra hacks such as creating upstart script to fix the permission on /tmp during boot process as stated at http://serverfault.com/questions/427626/how-to-mount-tmp-in-mnt-on-ec2

As a solution you should either implement as

mounts: ephemeral0:

[/tmp, auto, 'defaults,nobootwait,noatime', '0', '2' ]
[/tmp, "root:root, 1777]

or

[ ephemeral0, /tmp, 'defaults', '0', '2', 'ubuntu:ubuntu', '0755']

otherwise this bug makes cloud-init not very usable for mount management

May 09 '23 18:05 ubuntu-server-builder

Launchpad user traylenator(traylenator) wrote on 2014-11-14T09:56:54.956414+00:00

This is particularly in the way with CentOS 7 it seems where when the system reboots the boot process stops early as /tmp is not writable.

May 09 '23 18:05 ubuntu-server-builder

Launchpad user Graham Leggett(minfrin-y) wrote on 2018-03-08T17:41:27.053866+00:00

We just ran into this issue trying to get cloud-init to create a dedicated partition for /var/tmp. It creates the mount, but with the wrong permissions, and thus breaks the machine.

We've had to hack our config to work around the problem, which is really ugly.

May 09 '23 18:05 ubuntu-server-builder

This feature request was first created in 2011. Is there any plan to someday implement it ? Or are there other ways to do it ?

Jul 08 '23 08:07 vjau

Hey @vjau , unfortunately this just hasn't been seen as a priority given its age and initial triage status. Given that a few people have commented asking for this and it sounds like it should be relatively straightforward, I'll try to get it a little higher on the priority list.

Jul 11 '23 14:07 TheRealFalcon

Addressing some past points

[ec2-user@ip-10-234-85-230 ~]$ mkdir -p /mnt/ephemeral/var.live mkdir: cannot create directory `/mnt/ephemeral/var.live': Permission denied

it looks like a chmod is not implemented

correct, cloud-init just mounts the filesystem, it does not modify it

Yes something like this. [ ephemeral0, /mnt/ephemeral, auto, "defaults", "ubuntu:ubuntu", 0755 ]

Hm... i suppose we could add a field there, but it wouldn't be ideal. I like the fact that the fields represent exactly what is in /etc/fstab.

-1 to that proposal, I agree with Scott. Stuffing random data into a field which currently exactly matches fstab's format would be a surprising and ugly UI choice.

Or are there other ways to do it ?

A better solution would be nice, but in the meantime you can add the following to your cloud-config:

runcmd:
   - chmod <mode> /mnt/ephemeral/

where <mode> represents whatever mode you prefer for your mount

A better solution

A cloud-config that was designed with more foresight to potential changes might have made the values under mounts be objects with key names rather than a list of lists of strings.

Doing this would allow multiple fields to be associated with a mount, something like:

mounts:
   - fstab: [ ephemeral0, /mnt/ephemeral, auto, "defaults" ]
     mode: 1777
   - fstab: [ swap, none, swap, sw, "0", "0" ]

I suppose that we could add support for something like this, but if we do we should probably deprecate the old format. I wouldn't consider this change straightforward, and since a workaround exists I'm dropping the priority label.

Jul 03 '24 19:07 holmanb

runcmd will only run once per instance, so that would only work on the first boot. But also the mounts module only runs once per instance too, so it seems that module isn't a good candidate for a solution here anyway.

Jul 03 '24 19:07 TheRealFalcon

runcmd will only run once per instance, so that would only work on the first boot. But also the mounts module only runs once per instance too, so it seems that module isn't a good candidate for a solution here anyway.

Good point. per-boot would only be needed for ephemeral mountpoints, but that is what was being asked in this issue I suppose.

Jul 03 '24 21:07 holmanb