[SOLVED]Logs permissions for Docker Install
-
Not a big issue simply a request if easily doable.
The MSR logs files inside the container are owned by root witch is fine however, the permissions are very restrictive. I do not know if there is something wrong with my installation but the logs permission are set to 222 (write only). Even if the docker volume is set for Read/Write the log files are retaining these values.
I go around the problem by doing a chmod 777 on all reactor logs but every time there is an MSR log rotation the permissions are set back to 222. So unless the permission are implemented in the container there is no permanent solution to this (that I know of).
I do not know much about Docker container so I do not know what is involved here.
Can the logfiles permission be simply chaged in the container to at least allow "other" read permission?
Could the MSR log rotation routine implement a chmod to set the permission?
Just a small anoyance
Thanks
-
There should not be any log files inside the container. You should not have any reason to access anything inside the container.
-
Ok, I guess that I did not put enough information to be clear. I skipped the intro and went directely into what I beleive to be the issue. I should stick with the issue not the solution. My bad.
I do not go in the container to access the logs or change permissions but I did looked at them, trying understand how that works. Docker volumes, map the /var/reactor of the container to a directory on the host with read/write premissions. From the host it is then, via samba, shared to my PC where I would like to access the logs.
Because of the permissions of the files, I cannot access the files directely from my PC. I have to change the permissions on the Host before I can access them (It can however, be access from the hosts by using "sudo" ).
What I was trying to say in my initial post is that the permission are set to 222 in the container that get mapped to the the hosts and eventually to my PC. Changing the permissions on the host is only temporary until Reactor do a log rotation where the files changed back to 222. If the logfiles in the container were created with something like 226 the "read" permission for "other" would ripple all the way to the hosts a then to the PC.
Like I said in my first post, I am not a Docker specialist but I thought that the only way to permanentely change the logs permissions would be by the application at the container level where they are created.
That being said, I have been wrong before!
Again, not a big deal just convenience.
-
Please do an
ls -l
(on the docker host system) of the directory that's mapped to/var/reactor
, and anls -l
of yourlogs
directory. And, please post the contents of yourconfig/logging.yaml
file.There's something definitely not right with your setup. Files produced by my containers are owned by root, that's normal, but that 222 permission is not something I've ever seen.
-
All my docker applications, including reactor, have a volume in my "automation" folder on the host.
vezinpi@RPI8G:~/automation $ ls -l total 32 drwxr-xr-x 2 vezinpi vezinpi 4096 May 28 2023 docker-compose drwxrwxrwx 4 vezinpi vezinpi 4096 Jan 14 13:41 esphome drwxrwxrwx 8 472 472 4096 Feb 8 07:45 grafana drwxrwxrwx 12 vezinpi vezinpi 4096 Feb 6 15:25 homeassistant drwx------ 3 vezinpi root 4096 Feb 22 2023 influxdb2 drwxrwxrwx 6 vezinpi vezinpi 4096 Jun 20 2024 reactor drwxr-xr-x 9 vezinpi root 4096 Feb 8 03:28 ssl drwxrwxrwx 11 vezinpi vezinpi 4096 Feb 8 07:52 zwave-js-ui
Here is the reactor folder:
vezinpi@RPI8G:~/automation $ ls -l reactor total 64 drwxrwxrwx 2 vezinpi vezinpi 4096 Feb 5 21:38 config drwxrwxr-x 2 root root 4096 Feb 6 14:07 dist-config drwxrwxrwx 2 vezinpi vezinpi 4096 Feb 8 06:23 logs -rwxrw-rw- 1 vezinpi vezinpi 45473 Jan 3 2022 reactor-config-backup.json drwxrwxrwx 7 vezinpi vezinpi 4096 Jun 20 2024 storage vezinpi@RPI8G:~/automation $
Here is the log folder. Please note that some files still have read/write permissions for "other" . This is me changing the permission on the host to grant me access from my PC. The most recent one are back to write only (222). As the log rotation progresses they will all become 222.
vezinpi@RPI8G:~/automation/reactor $ ls -l logs total 44688 -rwxrw-rw- 1 vezinpi vezinpi 6572 Feb 6 14:07 hass_config.json -rwxrw-rw- 1 vezinpi vezinpi 288139 Feb 6 14:07 hass_services.json -rwxrw-rw- 1 vezinpi vezinpi 308677 Feb 6 14:07 hass_states.json --w--w--w- 1 root root 1802037 Feb 8 08:02 reactor.log --w--w--w- 1 root root 4194194 Feb 8 06:23 reactor.log.1 --w--w-rw- 1 root root 4194347 Feb 7 06:16 reactor.log.10 --w--w-rw- 1 root root 4194366 Feb 8 02:48 reactor.log.2 --w--w-rw- 1 root root 4193980 Feb 7 21:59 reactor.log.3 --w--w-rw- 1 root root 4194236 Feb 7 19:04 reactor.log.4 --w--w-rw- 1 root root 4194260 Feb 7 17:18 reactor.log.5 --w--w-rw- 1 root root 4194318 Feb 7 15:13 reactor.log.6 --w--w-rw- 1 root root 4194256 Feb 7 12:39 reactor.log.7 --w--w-rw- 1 root root 4193917 Feb 7 10:39 reactor.log.8 --w--w-rw- 1 root root 4194228 Feb 7 09:10 reactor.log.9 -rw-r--r-- 1 root root 11755 Feb 5 19:45 unhandled.json -rwxrw-rw- 1 vezinpi vezinpi 24164 Feb 28 2022 vera-status-initial.json -rwxrw-rw- 1 vezinpi vezinpi 48401 Feb 28 2022 vera-user_data-initial.json -rwxrw-rw- 1 vezinpi vezinpi 1263301 Nov 6 2022 zwavejs_devices_initial.json vezinpi@RPI8G:~/automation/reactor $
config/logging.yaml
vezinpi@RPI8G:~/automation/reactor/config $ more logging.yaml --- logging: default: level: 4 streams: - type: console level: 0 - type: file name: "reactor.log" mode: 0666 maxsize: 4 # megabytes max size keep: 10 # copies of old logs # # capture_console: if true, (most) console output will be captured to # this stream (if you have multiple streams, this # feature can only be used by ONE of them). If you # turn this on (true), set the "console" type stream # (above) log level to 0 to avoid duplicate logging # entries. The default is false, console not captured. #capture_console: true app: level: 4 httpapi: level: 4 httpproxy: level: 4 wsapi: level: 4 Structure: level: 4 Controller: level: 4 OWMWeatherController: level: 4 VeraController: level: 4 HubitatController: level: 4 HassController: level: 4 Rule: level: 5 Engine: level: 5 (END)
Hope this help
-
The YAML parser doesn't like the octal value in
mode: 0666
. The parser library changed standard a while back, and I guess there's so little use of octal in Reactor that yours is the first report that points back to it.Change your
mode: 0666
tomode: 0o666
.Additional note/edit here: Use of
0o
as a prefix for octal is the YAML 1.2 (2009) standard. Many web-based YAML editors don't support this standard, and will parse that form incorrectly. For example, the YAML editor at codebeautify.org currently parses0o644
as 0. The YAML checker at yamllint.com works correctly with0o
prefixing (fortunately). Be careful what tools you're using out there, and be suspicious around octal values until you know they are parsed correctly. -
Super, it worked as expected.
My MSR installation date from all the way back at the begining of this treck. I do recollect adjusting the # of logs and size but not adding the "mode". In any case, I see from the dist-config/logging.yaml that the default is 0644 (which would work just fine) and that it is commented out. That is probably what everybody have and the reason why I was the lone woolf out there. I think I will follow the pack and comment it out.
EDIT: I did add the "mode" back in dec 2021 to fix a similar issue. Things have changed/evolved since causing the issue to show up again.
Many thanks
-
Super, it worked as expected.
My MSR installation date from all the way back at the begining of this treck. I do recollect adjusting the # of logs and size but not adding the "mode". In any case, I see from the dist-config/logging.yaml that the default is 0644 (which would work just fine) and that it is commented out. That is probably what everybody have and the reason why I was the lone woolf out there. I think I will follow the pack and comment it out.
EDIT: I did add the "mode" back in dec 2021 to fix a similar issue. Things have changed/evolved since causing the issue to show up again.
Many thanks
@vezinpi said in [SOLVED]Logs permissions for Docker Install:
from the dist-config/logging.yaml that the default is 0644 (which would work just fine)
Yes, and that needs to read
0o644
now -- I've fixed that for the next build. The default is actually0o640
in the code, so I've fixed the distribution template for that as well.