Method 1: Copy Files Directly with docker cp

While you cannot mount a new volume on a running container, you can transfer files between your host and the container using the docker cp command. This is useful for one-time file transfers but does not create a persistent mount.

Command Syntax:

bash# Copy from container to host
docker cp <containerId/containerName>:/path/in/container /path/on/host

# Copy from host to container
docker cp /path/on/host <containerId/containerName>:/path/in/container

Example:

bashdocker cp my_container:/app/config.json ./local_dir
docker cp ./updated_file.txt my_container:/app/data

Limitations:

• No real-time synchronization; changes are not automatically reflected.

• Manual process; must be repeated for each transfer2.

For more details, see the [Docker documentation on docker cp]2.

Method 2: Commit and Recreate the Container with a Volume

For persistent storage, the best approach is to commit your running container to a new image and then launch a new container with the required volume mount.

Steps:

1. Commit the existing container:

    bashdocker commit <containerId or containerName> new_image_name
   

2. Run a new container with a volume:

    bashdocker run -v /host/path:/container/path -it new_image_name /bin/bash
   

Example workflow:

bashdocker commit agitated_newton my_ubuntu
docker run -v "$PWD/somedir":/somedir -it my_ubuntu /bin/bash

Advantages:

• Enables persistent storage via Docker-managed volumes or bind mounts16.

• Retains changes made in the original container.

Note: This method requires stopping the old container and using the new one for continued work4.

Why Can’t You Mount Storage Directly on a Running Container?

Docker’s architecture does not support adding new mounts to a running container. Mounts (volumes, bind mounts, tmpfs) must be specified at container creation using the --mount or -v flags16. For persistent or shared storage, always plan your mounts before starting the container.

Summary Table

Why Does SSH Access Get Blocked?

A common mistake is enabling a firewall (like ufw) inside your VM without explicitly allowing port 22. Even if your Google Cloud VPC firewall allows SSH, a restrictive internal firewall can block all incoming SSH connections, leaving you unable to connect.

Step-by-Step Recovery Guide

1. Stop Your VM

• Go to your VM instance in the Google Cloud Console.

• Click Stop to shut down the VM. This is required to make certain configuration changes.

2. Enable Serial Console Access

• With the VM stopped, click Edit.

• Scroll to the “Enable connecting to serial ports” option and check the box.

• Save your changes. This feature lets you interact with your VM as if you were physically at its terminal.

3. Add a Startup Script to Create a Temporary Admin User

• In the VM settings, find the “Automation” or “Metadata” section.

• Add a startup script like this:

#!/bin/bash
useradd -m tempadmin
echo 'tempadmin:TempPassword123!' | chpasswd
usermod -aG sudo tempadmin

Replace tempadmin and TempPassword123! with your own username and a strong, temporary password.

4. Restart the VM

• Start your VM. The startup script runs automatically, creating a new user with sudo privileges.

5. Connect via Serial Console

• From the VM’s page, click Connect to Serial Console.

• Log in with the temporary username and password you set in the script.

6. Re-Enable SSH Access

• Once logged in, run:

sudo ufw allow 22

This command opens port 22 for SSH.

7. Clean Up for Security

• Stop the VM again.

• Remove the startup script from the metadata to prevent it from running again.

• Disable serial port access for security.

• Restart the VM.

• Log in via SSH as usual.

• Delete the temporary user after confirming SSH works:

sudo deluser tempadmin
sudo rm -rf /home/tempadmin

Best Practices

• Always allow port 22 in both your VM and VPC firewalls before enabling ufw.

• Remove temporary users and scripts as soon as you regain access.

• Regularly back up your VM to avoid future lockouts.

Quick Reference Table