How to mount /tmp in /mnt on EC2?
Solution 1
There are a couple problems with the initial suggestion you list, though it seems like it's headed in a good direction:
-
For security purposes, the
mkdir
command should create the directory with the sticky bit set in the mode:mkdir -m 1777 /mnt/tmp
The
-o nobootwait
doesn't seem necessary as this is not being saved in/mnt/fstab
.
So, I'd recommend trying this in /etc/rc.local
:
test -d /mnt/tmp || mkdir -m 1777 /mnt/tmp
mount --bind /mnt/tmp /tmp
Any attempt to put the bind mount in /etc/fstab
is going to run into problems when you stop/start the instance or when you create an AMI and run a new instance as /mnt is ephemeral storage and all contents (including the /mnt/tmp
directory) are going to disappear.
Solution 2
A more robust approach, since you're running Ubuntu, would be to put Eric Hammond's suggestion inside an Upstart script, and have the bind done immediately after mounting /mnt
:
# File /etc/init/mounted-mnt.conf
# mounted-mnt - Binds /tmp to /mnt/tmp
description "Binds /tmp to /mnt/tmp"
start on mounted MOUNTPOINT=/mnt
task
script
test -d /mnt/tmp || mkdir -m 1777 /mnt/tmp
mount --bind /mnt/tmp /tmp
end script
Some servers, like Apache/Passenger, might create important temporary files on /tmp
. Once rc.local
– the last in the boot sequence – ran they would get hidden and confuse the servers.
Solution 3
The idea of using an Upstart script as suggested by Romulo Ceccon is great. However, you may not want to hide the magic inside an obscure script. It's perfectly ok to add the mount inside fstab, e.g.
LABEL=cloudimg-rootfs / ext4 defaults 0 0
# auto mount ephemeral storage (if any)
# init contents in /etc/init/mounted-local*.conf
/dev/xvdb /mnt/local1 auto defaults,nofail,nobootwait,comment=cloudconfig 0 2
/dev/xvdc /mnt/local2 auto defaults,nofail,nobootwait,comment=cloudconfig 0 2
/dev/xvdd /mnt/local3 auto defaults,nofail,nobootwait,comment=cloudconfig 0 2
/dev/xvde /mnt/local4 auto defaults,nofail,nobootwait,comment=cloudconfig 0 2
# bind /tmp to /mnt/local1, might still be on / if no ephemeral storage
/mnt/local1 /tmp none bind
And this is the Upstart script:
# File /etc/init/mounted-local1.conf
# mounted-local1 - init ephemeral storage in /mnt/local1
description "Initializes ephemeral storage in /mnt/local1"
start on mounted MOUNTPOINT=/mnt/local1
# provide defult, see /etc/init/mounted-tmp.conf for details
env MOUNTPOINT=/mnt/local1
task
script
# fix permissions if needed
test -d $MOUNTPOINT && chmod 1777 $MOUNTPOINT
# log to /var/log/upstart/mounted-local1.log
#echo "initialized $MOUNTPOINT"
end script
This way, you could create any directory structure and what not on ephemeral storage.
All that's left is mkdir -p /mnt/local{1..4}
and a restart (I wouldn't mount /tmp without as you would hide current files there).
Related videos on Youtube
Autsada
Rails developer, GNU/Linux operating system teacher, system administrator.
Updated on September 18, 2022Comments
-
Autsada over 1 year
I was wondering what is the best way to mount the
/tmp
endpoint in the ephemeral storage/mnt
on an EC2 instance and give theubuntu
user default write permissions.Some suggest editing /etc/rc.local this way:
mkdir -p /mnt/tmp && mount --bind -o nobootwait /mnt/tmp /tmp
However that doesn't work for me (files differs).
I tried editing the default fstab entry:
/dev/xvdb /mnt auto defaults,nobootwait,comment=cloudconfig 0 2
replacing /mnt with /tmp and and giving it a umask=0777, however it doesn't work because of cloudconfig.
I'm using Ubuntu 12.04. Thanks.
-
loislo over 11 yearsI can't figure out what you're asking me to do. Can you provide an example of the expected output using
touch
andls -l
?
-
-
Autsada over 11 yearsCan you recommend putting this in user-data scripts?
-
Skaperen over 11 yearsI would take the approach of coding rc.local to first attempt a mount of the ephemeral device (did he already mount it at /mnt ?), and if that fails, format it and try mounting again. That way a stop and restart should preserve it (terminate would be the way to start fresh, as usual). I don't see a definite need to have it in /etc/fstab since rc.local mount it, but having rc.local append it probably won't hurt.
-
Eric Hammond over 11 years@ClaudioPoli: The problem with putting this in user-data is that the user-data script is only run on the first boot. You want this to run on every boot. You could have user-data add this to /etc/rc.local, but make sure it's inserted before any "exit" statement in that file.
-
Eric Hammond over 11 years@Skaperen: /mnt is generally formatted cleanly and mounted on every run or start of an instance. A stop/start gives you a clean, fresh /mnt with no data left over from previous running. Any modification you wanted to make to /etc/fstab would be preserved through stop/start, so it would not make sense to have rc.local modify it on every boot.
-
Tom O'Connor about 11 yearsIntriguing idea..
-
Saroj about 10 yearsWill the mount via fstab succeed if there's no
/mnt/local1
? Perhaps the mounting event is safer. -
sfussenegger about 10 yearsYes, I assumed that /mnt/local1 is available. I should have explained, that nothing is mounted on /mnt which typically is the case. Creating this directory therefore is part of the setup. I haven't tried using the mounting event, but maybe you are right. The main point of my answer is that it might be better to keep mounts in the fstab file and do stuff like the
chmod 1777
ormkir -p
in upstart scripts.