Controller does not survive VM reboots because logs directory becomes owned by root

## Environment details:

```
Vagrant 2.2.2
VirtualBox 5.2.22
```
I installed and deployed openwhisk on my VM, everything works, and after I halt and up my VM, container `controller0` didn't restart.

## Problem
```
$ wsk action invoke /whisk.system/utils/echo -p message hello --result
error: Unable to invoke action 'utils/echo': The connection failed, or timed out. (HTTP status code 502)
Run 'wsk --help' for usage.
```

```

$docker ps

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
0065e443fe44 openwhisk/nodejs6action:latest "/bin/sh -c 'node --…" 19 minutes ago Up 19 minutes wsk00_1_prewarm_nodejs6
f619e5edc8ee openwhisk/nodejs6action:latest "/bin/sh -c 'node --…" 19 minutes ago Up 19 minutes wsk00_2_prewarm_nodejs6
2217244839da openwhisk/apigateway:latest "/usr/bin/dumb-init …" 23 hours ago Up 19 minutes 80/tcp, 8423/tcp, 0.0.0.0:9000->9000/tcp, 0.0.0.0:9001->8080/tcp apigateway
029a75a5f5e8 redis:4.0 "docker-entrypoint.s…" 23 hours ago Up 19 minutes 0.0.0.0:6379->6379/tcp redis
9b6da30c0621 nginx:1.13 "nginx -g 'daemon of…" 23 hours ago Up 19 minutes 0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp, 0.0.0.0:8443->8443/tcp nginx
4388cbbf8018 whisk/invoker:latest "/bin/sh -c 'exec /i…" 23 hours ago Up 19 minutes 0.0.0.0:17000->17000/tcp, 0.0.0.0:18000->18000/tcp, 0.0.0.0:12001->8080/tcp invoker0
0d0aa2b2aa32 whisk/controller:latest "/bin/sh -c 'exec /i…" 24 hours ago Restarting (1) 51 seconds ago controller0
3b22f6989fda wurstmeister/kafka:0.11.0.1 "start-kafka.sh" 24 hours ago Up 19 minutes 0.0.0.0:9072->9072/tcp, 0.0.0.0:9093->9093/tcp kafka0
db9f028e808d zookeeper:3.4 "/docker-entrypoint.…" 24 hours ago Up 19 minutes 0.0.0.0:2181->2181/tcp, 0.0.0.0:2888->2888/tcp, 0.0.0.0:3888->3888/tcp zookeeper0
f873c68b1cd7 apache/couchdb:2.1 "tini -- /docker-ent…" 25 hours ago Up 19 minutes 0.0.0.0:4369->4369/tcp, 0.0.0.0:5984->5984/tcp, 0.0.0.0:9100->9100/tcp couchdb

```

```
$docker logs 0d0aa2b2aa32
/bin/sh: can't create /logs/controller0_logs.log: Permission denied
```

Start with the Docker-based VM deployment configuration that creates or mounts the controller's /logs directory, then reproduce the halt-and-up cycle described in the issue. Use `docker logs controller0` to confirm the permission error; done means controller0 restarts successfully and the action invocation no longer returns HTTP 502.

Written by the indexing model from the issue text.