Rename Home Directory broke docker desktop

Docker Desktop
,
1

Hello Community,

I recently renamed my home directory on Monterey 12.6 (latest) 16 inch 2021 M1 Max 32G Ram . As far as I can tell, the only thing that doesn’t work correctly is Docker.

Troubleshooting I have done.

  1. First, I removed docker from my applications, emptied the trash and reinstalled.
    After this, docker could not start at all. The error was a popup saying it couldn’t find my home directory
    and was looking for the old directory.

  2. I then followed the list of instructions below I found online, except I removed them in the term instead of using finder. Some of the directories no longer existed.

    Click the File menu in Finder and choose Go to Folder.
    Go over the files in the following paths and move them to the Trash.

    ~/Library/Caches/com.docker.docker

    ~/Library/Cookies/com.docker.docker.binarycookies

    ~/Library/Group Containers/group.com.docker

    ~/Library/Logs/Docker Desktop

    ~/Library/Preferences/com.docker.docker.plist

    ~/Library/Preferences/com.electron.docker-frontend.plist

    ~/Library/Saved Application State/com.electron.docker-frontend.savedState

    ~/.docker

    /Library/LaunchDaemons/com.docker.vmnetd.plist

    /Library/PrivilegedHelperTools/com.docker.vmnetd

    /usr/local/lib/docker

3, After this, I downloaded a new docker install file and ran the install. Docker now runs, but when I run docker compose ps I get the following error: open /Users/oldhomedirectory/go/src/levtk/.env: no such file or directory

If I run docker compose -f ./docker-compose-yml build the command works as expected.

Do you know where the compose sub-command is caching the files I need to manually delete?

2

I don’t think it is caching anyehere, but when you run containers with docker compose, it will add labels to you containers. So when you run docker compose ls -a it will know which container belongs to which project. For example these are the labels of my container in a test project:

docker container inspect compose-test-bash-1 --format '{{ json .Config.Labels }}' | jq

{
   "com.docker.compose.config-hash": "0409f24bca13c07d39bb7cc434242767beeeff2d020ee858f43913d9c0a24121",
  "com.docker.compose.container-number": "1",
  "com.docker.compose.depends_on": "",
  "com.docker.compose.oneoff": "False",
  "com.docker.compose.project": "compose-test",
  "com.docker.compose.project.config_files": "/Users/ta/Data/projects/testprojects/compose-test/docker-compose.yml",
  "com.docker.compose.project.working_dir": "/Users/ta/Data/projects/testprojects/compose-test",
  "com.docker.compose.service": "bash",
  "com.docker.compose.version": "2.10.2"
}

As you can see it contains the full path of the compose file and the project itself. If docker compose build rebuilds your project and recreates your container, the issue can go away.

I am not sure that this is the issue, but I don’t know any other way that compose uses to store the paths of old directories