I get error 13 permission denied on .cache

[disi]

Describe the bug I get error 13 permission denied on '.cache'

To Reproduce Steps to reproduce the behavior:

1. Add 2.0 via HACS
2. Restart Home Asisstant
3. Setting Devices -> Add Integration and enter credentials
4. ERROR (MainThread) [custom_components.toyota.config_flow] An unknown error occurred during login request: [Errno 13] Permission denied: '.cache'

Expected behavior Add my account to the integration.

Screenshots ERROR (MainThread) [custom_components.toyota.config_flow] An unknown error occurred during login request: [Errno 13] Permission denied: '.cache'

Additional context This is 2024.1.2 run as docker version.

I only found the .cache folder directly under /hass_config/.cache and tried to rremove, reinstall through HACs, there are subfolders named 'pip' and 'http' in there. I am not sure, I am looking the the correct folder.

[CM000n]

Hi @disi. The .cache folder is created in the home directory of the Docker container user. In my case, for example, this is the /root directory within the container:

Strange, actually the container user should also have the right to write to his home directory. Or are you running the Home Assistant process yourself via another user?

[disi]

I tried recreating it:

[root@dombox hass_config]# mkdir .cache
[root@dombox hass_config]# chown -R 911:911 .cache/
[root@dombox hass_config]# ls -la .cache
total 4
drwxr-xr-x.  2 911 911    6 Jan 15 10:48 .
drwxr-xr-x. 15 911 911 4096 Jan 15 10:49 ..

Everything under hass_config is owned by 911. And restarted the entire homeassistant container, same error. Even changing 777 on the folder, gives the same error. Starting homeassistant without the folder, same error. From within the container: The user within the container is: abc:x:911:911::/config:/bin/false

My /hass_config is mapped as a volume into /config

[CM000n]

The .cache folder is, as already written, not created in the config directory of your Home Assistant, but in the home directory of the user with whom the Home Assistant process is executed! So it has nothing to do with your /hass_config folder 😉

[disi]

I don't understand where else it would look for it. In the setup I have: All files are written by the user "abc" from within the container with user id 911. Its home directory is /config inside the container. /hass_config on the host system is mapped as /config into the container. So I believe the .cache folder should be in /hass_config/.cache or within the container /config/.cache.

There was a folder with this name before and permissions 911:911, I even tried to change it with all write permissions, and tried recreating the folder.

I get the user input form from config_flow.py, I enter my credentials, no matter if correct or not I get the error about permissions on .cache when I hit Submit.

p.s. going back to 1.3, it creates the .cache folder where I expected it and create some subfolder /config/.cache/pip

[CM000n]

p.s. going back to 1.3, it creates the .cache folder where I expected it and create some subfolder /config/.cache/pip

That makes absolutely no sense. Version 1.3 never created a .cache folder itself. Especially not for pip files. This has nothing to do with each other.

What does your docker-compose file look like, if you have one?

What is the user behind the id 911? id -nu 911 An attempt is made to create the .cache folder in its home directory: eval echo ~<User Name from command output above>

[disi]

V 1.3 2024-01-15 13:27:52.001 INFO (SyncWorker_10) [homeassistant.util.package] Attempting install of mytoyota==0.9.3 installed to /config/.cache/pip v 2.0 2024-01-15 13:31:29.559 INFO (SyncWorker_0) [homeassistant.util.package] Attempting install of mytoyota>=1.2.0 installed to /config/.cache/pip I believe this is just a hash of the version installed of the python library of mytoyota.

But with 1.3 I do not get the .cache error as in 2.0.

From within the container:

root@dombox.dom:/# id -nu 911
abc
root@dombox.dom:/# eval echo ~abc
/config

Some testing:

[root@dombox ~]podman exec -it homeassistant /bin/bash
root@dombox.dom:/# sudo -S -u abc whoami
bash: sudo: command not found
root@dombox.dom:/# apk add sudo
(1/1) Installing sudo (1.9.13_p3-r2)
Executing busybox-1.36.1-r5.trigger
OK: 237 MiB in 194 packages
root@dombox.dom:/# sudo -S -u abc whoami
abc
root@dombox.dom:/# sudo -S -u abc mkdir ~/.cache
mkdir: cannot create directory ‘/config/.cache’: File exists
root@dombox.dom:/# sudo -S -u abc touch ~/.cache/test
root@dombox.dom:/# exit
exit
[root@dombox ~]# ls /stratis/hass_config/.cache/
pip  test

I looked at the mytoyota libary: https://github.com/DurgNomis-drol/mytoyota/blob/master/mytoyota/controller.py Then tested inside the containter:

root@dombox.dom:/# sudo -S -u abc python
Python 3.11.6 (main, Oct  4 2023, 06:22:18) [GCC 12.2.1 20220924] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from pathlib import Path
>>> print(Path.home())
/config

Then created the file manually, that controller.py looks at:

[root@dombox ~] touch /stratis/hass_config/.cache/toyota_credentials_cache_contains_secrets
[root@dombox ~]chown 911:911 /stratis/hass_config/.cache/toyota_credentials_cache_contains_secrets

Different error now, so I know it uses the correct directory: 2024-01-15 14:30:50.544 ERROR (MainThread) [custom_components.toyota.config_flow] An unknown error occurred during login request: Expecting value: line 1 column 1 (char 0

[CM000n]

V 1.3 2024-01-15 13:27:52.001 INFO (SyncWorker_10) [homeassistant.util.package] Attempting install of mytoyota==0.9.3 installed to /config/.cache/pip v 2.0 2024-01-15 13:31:29.559 INFO (SyncWorker_0) [homeassistant.util.package] Attempting install of mytoyota>=1.2.0 installed to /config/.cache/pip I believe this is just a hash of the version installed of the python library of mytoyota.

You are mixing things up here. This is not a .cache folder that is created by the mytoyota lib itself, but a folder for caching pip files. This is handled entirely by the respective python env itself.

I don't want to be offensive, but you really have a very strange config of your container and home assistant 😉

Sorry, but this looks to me less like a actual problem with the mytoyota Python lib and ha_toyota Custom Componenent and more like a misconfiguration of the linux permissions.

What happens when you try to create the folder inside the python REPL with pathlib? That would be the same process that the mytoyota lib uses.

[disi]

This works:

[root@dombox ~]# podman exec -it homeassistant /bin/bash
root@dombox.dom:/# sudo -S -u abc python
Python 3.11.6 (main, Oct  4 2023, 06:22:18) [GCC 12.2.1 20220924] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from pathlib import Path
>>> import json
>>> CACHE_FILENAME: Path = Path.home() / ".cache" / "toyota_credentials_cache_contains_secrets"
>>> CACHE_FILENAME.parent.mkdir(parents=True, exist_ok=True)
>>> with open(str(CACHE_FILENAME), "w", encoding="utf-8") as f:  f.write(  json.dumps(  {   "access_token": "None",   "refresh_token": "None",   "uuid": "None",     "expiration": "None",    "username": "None",   },    default=str,    )  )

File is created with content.

[root@dombox ~]# ls -la /stratis/hass_config/.cache/
total 8
drwxr-xr-x.  2 911 911   55 Jan 15 15:29 .
drwxr-xr-x. 16 911 911 4096 Jan 15 15:38 ..
-rw-r--r--.  1 911 911  107 Jan 15 15:35 toyota_credentials_cache_contains_secrets

[CM000n]

This looks good. But presumably setting up the custom component still fails, I assume? What does your output from top look like?

Another possibility would be that you increase the logging level of the mytoyota python lib and see if there is any information there when you use it to set up the custom component again. Unfortunately, I have not yet been able to reproduce this behaviour.

[disi]

OK!!!1111111elevenoneone

I was using the linuxserver.io home assistant image docker.io/linuxserver/homeassistant. Now I switched to ghcr.io/home-assistant/home-assistant:latest

AND it works!

Thank you for your patience :)

Actual it did not create files under .cache...

[CM000n]

Very nice! Good to see it works for you now 😊

[radustanila]

Same error on HA Core 2014.1.2 python 3.11.7 venv ERROR (MainThread) [custom_components.toyota.config_flow] An unknown error occurred during login request: [Errno 13] Permission denied: '.cache' Ubuntu 22.04 kernel 6.2.0-39-generic After running simple_client_example.py from mytoyota module the cache file is created. The integration is working after this step.

[CM000n]

This all sounds like the Home Assistant process is being started by a user who does not have permission to create the .cache folder.

This depends heavily on your personal environment and configuration for ACL permissions.

Unfortunately, we can only help to a limited extent here, as we do not know and cannot understand your personal environments.

[jprihoda]

Hi, I'm having exactly the same issue. I have verified multiple times that my Home Assistant is running under the same user who owns the .cache directory in the home folder. Even changing the permissions of the .cache directory to 777 didn't resolve the issue. (HA Core 2024.1.3 python 3.11.3 venv)

[ingvarso]

Same issue for me as well. Using the linuxserver.io home assistant image.

lscr.io/linuxserver/homeassistant:2024.1.5

Tried the steps above and creating the file manually from python, and that works without errors.

$ docker exec -itu 1000 homeassistant python
Python 3.11.6 (main, Oct  4 2023, 06:22:18) [GCC 12.2.1 20220924] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from pathlib import Path
>>> import json
>>> CACHE_FILENAME: Path = Path.home() / ".cache" / "toyota_credentials_cache_contains_secrets"
>>> CACHE_FILENAME.parent.mkdir(parents=True, exist_ok=True)
>>> with open(str(CACHE_FILENAME), "w", encoding="utf-8") as f:  f.write(  json.dumps(  {   "access_token": "None",   "refresh_token": "None",   "uuid": "None",     "expiration": "None",    "username": "None",   },    default=str,    )  )

$ docker exec -itu 1000 homeassistant /bin/bash
$ ls -l /config/.cache/toyota_credentials_cache_contains_secrets
-rw-r--r-- 1 abc users 107 Jan 26 08:31 /config/.cache/toyota_credentials_cache_contains_secrets

The process is running with User ID 1000 (abc)

$ id
uid=1000(abc) gid=1000(users) groups=1000(users)

$ ps aux | grep hass
abc          159  5.5 13.1 774996 483732 ?       Ssl  07:53   2:29 /config/lsiopy/bin/python3 /lsiopy/bin/hass -c /config

[CM000n]

As already written above: https://github.com/DurgNomis-drol/ha_toyota/issues/208#issuecomment-1892348974 This is more a problem with the authorisation settings of the respective environment. We can only help to a limited extent here.

A user here also wrote that the problem was solved for him after switching from the unofficial linuxserver.io container to the official Home Assistant container. https://github.com/DurgNomis-drol/ha_toyota/issues/208#issuecomment-1892521098