Many developers working with Docker on Ubuntu servers face a recurring issue where the docker.sock permissions reset after reboot. The default permissions (typically 660) often require manual intervention with:

sudo chmod 666 /var/run/docker.sock

This becomes particularly problematic when you need services to automatically start with proper Docker access after system reboot.

The most reliable approach is creating a systemd unit file that executes before Docker starts. Here's how to implement it:

# /etc/systemd/system/docker-socket-perms.service
[Unit]
Description=Set Docker socket permissions
Before=docker.service
Requires=local-fs.target

[Service]
Type=oneshot
ExecStart=/bin/chmod 666 /var/run/docker.sock
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

For systems where systemd isn't available or suitable, you can create a udev rule:

# /etc/udev/rules.d/99-docker-sock.rules
KERNEL=="docker0", NAME="%k", GROUP="docker", MODE="0660"
KERNEL=="docker.sock", ACTION=="add", RUN+="/bin/chmod 666 /var/run/docker.sock"

After creating this file, reload udev rules with:

sudo udevadm control --reload-rules

While 666 permissions solve immediate access issues, consider these security alternatives first:

• Add service user to docker group: sudo usermod -aG docker $USER
• Configure specific ACLs: sudo setfacl -m user:serviceuser:rw /var/run/docker.sock
• Review Docker's group ownership: sudo chown root:docker /var/run/docker.sock

To verify the changes work after reboot:

sudo systemctl enable docker-socket-perms.service
sudo reboot
# After reboot
ls -l /var/run/docker.sock

You should see the permissions persist without manual intervention.

If permissions still reset:

# Check service execution logs
journalctl -u docker-socket-perms.service -b

# Verify unit file ordering
systemd-analyze critical-chain docker.service

# Check for competing udev rules
udevadm test /sys/class/net/docker0 2>&1 | grep docker.sock

When working with Docker on Ubuntu 16.04 systems, you might encounter permission issues with the Docker socket (/var/run/docker.sock). The socket's default permissions (typically 660) get reset on reboot, requiring manual intervention with:

sudo chmod 666 /var/run/docker.sock

While adding users to the docker group is the recommended approach, some legacy systems or specific applications may require the 666 permission setting.

The most reliable method is creating a systemd unit that executes before Docker starts:

# /etc/systemd/system/docker-socket-perms.service
[Unit]
Description=Set Docker socket permissions
Before=docker.service
Requires=docker.socket

[Service]
Type=oneshot
ExecStart=/bin/chmod 666 /var/run/docker.sock

[Install]
WantedBy=multi-user.target

Then enable and start the service:

sudo systemctl daemon-reload
sudo systemctl enable docker-socket-perms.service
sudo systemctl start docker-socket-perms.service

For systems using systemd, you can leverage the tmpfiles.d mechanism:

# /etc/tmpfiles.d/docker-socket.conf
f /var/run/docker.sock 666 root root -

The configuration will be applied at boot before most services start. Verify with:

sudo systemd-tmpfiles --create

While these solutions work, consider these security best practices:

• Prefer adding users to the docker group over global permissions
• For production systems, implement proper user/group isolation
• Consider upgrading from Ubuntu 16.04 (EOL) to a supported version
• Monitor socket access through auditd if using 666 permissions

If permissions still reset, check:

# Check service load order
systemd-analyze critical-chain docker.service

# Verify tmpfiles execution
journalctl -u systemd-tmpfiles-setup.service

# Check for competing services
systemctl list-dependencies docker.service