Permission Denied error

[eli007s]

After running the ubuntu-16.04-amd64-docker.json and try to spin up a new instance from the AMI created, I'm greeted wit this

`Welcome to Ubuntu 16.04 LTS (GNU/Linux 4.4.0-28-generic x86_64)

              ubuntu-16.04-amd64-docker (amazon-ebs)
                            ___ ___ ___
                           | __/ __|_  )
                           | _| (__ / /
                           |___\___/___|

                   Mon Jul 11 19:15:30 UTC 2016
                          Version: 0.1.0

System information as of Mon Jul 11 21:45:25 UTC 2016

System load: 0.0 Processes: 101
Usage of /: 9.0% of 9.71GB Users logged in: 1
Memory usage: 8% IP address for eth0: 10.0.0.0
Swap usage: 0%

Last login: Mon Jul 11 20:39:48 2016 from xx.xx.xx.xx
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
ubuntu@ip-10-0-0-0:~$ `

where can i track down what script is trying to access /dev/null?

thanks

[kwilczynski]

@eli007 thank you for reporting this. I have never seen this happening, but I will definitely have a look as soon as possible.

[kwilczynski]

@eli007 I had a look, and something indeed has changed in 16.04. The 14.04 is fine. What is happening, is that the /dev/null has incorrect permission set, as per:

ubuntu@ip-10-0-0-134:~$ ls -l /dev/null
crw-r--r-- 1 root root 1, 3 Jul 12 09:41 /dev/null

There is no write bit set for users and others, thus the error message we are seeing.

I am not entirely sure what these are not 0666, like it should be. I am going to have a look. This should be set correctly by udev, thus I am a bit puzzled. Also, it did worked in the past. I am going to review past commits and also check if this is still an issue when building a Vagrant box of 16.04 (which should be almost identical to the Amazon image).

The temporary fix would be: sudo chmod 0666 /dev/null

Sorry about this.

[eli007s]

HI,

this comes from the /scripts/common/cleanup.sh file somewhere.

removing this file from packer file causes the permission errors to go away. Altho I'm sure there is more under the hood in the cleanup bash, but its a starting point to investigate.

[kwilczynski]

@eli007 I suspect some package is causing this in 16.04, or some updated package. I can't see obvious reason for the permission change to be introduced by the clean-up.sh script itself, and it does work for 14.04 without any issues. It must be something 16.04 specific that has changed recently. I have not seen this happening about two weeks ago when I built Amazon image, it must have changed recently. I am having a look...

[kwilczynski]

@eli007 this does not seem to be affecting Vagrant box built for 16.04, which is good to know as it narrows it to 16.04 and EC2 builds.

[kwilczynski]

@eli007 the culprit was cloud-init. As here the file that I made a symbolic link to /dev/null gets written to, and the its permission is being changed to 0644 in here, which is not ideal on a healthy Linux distribution. Long story short, we don't want to have the /etc/network/interfaces.d/50-cloud-init.cfg file to be created by cloud-init and upset existing configuration, but I also don't want to disable network support in it completely. The change introduced in e1faa74 should resolve this for you.

I hope this helps! Sorry for troubles!