Closed redskinhu closed 3 years ago
Hello
There ia new developement....
The sensor value now is null. Restarted / reinstalled.
[s6-init] making user provided files available at /var/run/s6/etc...exited 0. [s6-init] ensuring user provided files have correct perms...exited 0. [fix-attrs.d] applying ownership & permissions fixes... [fix-attrs.d] done. [cont-init.d] executing container initialization scripts... [cont-init.d] done. [services.d] starting services [services.d] done. [Wed Feb 24 22:10:22 GMT 2021][Info] HDD Tools start [Wed Feb 24 22:10:22 GMT 2021][Info] Configuration - performance check enabled: false [Wed Feb 24 22:10:22 GMT 2021][Info] Configuration - disk path: /dev/nvme0 [Wed Feb 24 22:10:22 GMT 2021][Info] Configuration - check period: 1 [Wed Feb 24 22:10:22 GMT 2021][Info] Configuration - output file: temp.log [Wed Feb 24 22:10:22 GMT 2021][Info] Configuration - attributes property: [Wed Feb 24 22:10:23 GMT 2021][Info] Init run [Wed Feb 24 22:10:23 GMT 2021][INFO] Sensor value: null° [Wed Feb 24 22:10:23 GMT 2021][INFO] Sensor update response code: 200 [Wed Feb 24 22:10:23 GMT 2021][Info] Cron tab update [Wed Feb 24 22:10:23 GMT 2021][Info] Apply cron tab [Wed Feb 24 22:10:23 GMT 2021][Info] Device /dev/nvme0 not found - exiting [cmd] /run.sh exited 1 [cont-finish.d] executing container finish scripts... [cont-finish.d] done. [s6-finish] waiting for services. [s6-finish] sending all processes the TERM signal.
and here is the debug log:
"json_format_version": [
1,
0
],
"smartctl": {
"version": [
7,
2
],
"svn_revision": "5155",
"platform_info": "x86_64-linux-4.19.0-12-amd64",
"build_info": "(local build)",
"argv": [
"smartctl",
"-a",
"--json",
"/dev/nvme0"
],
"messages": [
{
"string": "Read NVMe Identify Controller failed: NVME_IOCTL_ADMIN_CMD: Permission denied",
"severity": "error"
}
],
"exit_status": 2
},
"device": {
"name": "/dev/nvme0",
"info_name": "/dev/nvme0",
"type": "nvme",
"protocol": "NVMe"
}
}```
version | core-2021.2.3
-- | --
Maybe this is related to the incompatibility with homeassistant 2021.2.0+ in 0.46. Can you please verify if the error is gone with the latest release? 0.47 is available.
0.47 installed on core-2021.3.2
Same issue, sensor value is null°
[s6-init] making user provided files available at /var/run/s6/etc...exited 0. [s6-init] ensuring user provided files have correct perms...exited 0. [fix-attrs.d] applying ownership & permissions fixes... [fix-attrs.d] done. [cont-init.d] executing container initialization scripts... [cont-init.d] done. [services.d] starting services [services.d] done. [Tue Mar 9 13:05:00 GMT 2021][Info] HDD Tools start [Tue Mar 9 13:05:00 GMT 2021][Info] Configuration - performance check enabled: false [Tue Mar 9 13:05:00 GMT 2021][Info] Configuration - disk path: /dev/nvme0 [Tue Mar 9 13:05:00 GMT 2021][Info] Configuration - check period: 1 [Tue Mar 9 13:05:00 GMT 2021][Info] Configuration - output file: temp.log [Tue Mar 9 13:05:00 GMT 2021][Info] Configuration - attributes property: [Tue Mar 9 13:05:00 GMT 2021][Info] Init run [Tue Mar 9 13:05:00 GMT 2021][INFO] Sensor value: null° [Tue Mar 9 13:05:00 GMT 2021][INFO] Sensor update response code: 200 [Tue Mar 9 13:05:00 GMT 2021][Info] Cron tab update [Tue Mar 9 13:05:00 GMT 2021][Info] Apply cron tab [Tue Mar 9 13:05:00 GMT 2021][Info] Device /dev/nvme0 not found - exiting [cmd] /run.sh exited 1 [cont-finish.d] executing container finish scripts... [cont-finish.d] done. [s6-finish] waiting for services. [s6-finish] sending all processes the TERM signal.
debug log:
"json_format_version": [
1,
0
],
"smartctl": {
"version": [
7,
2
],
"svn_revision": "5155",
"platform_info": "x86_64-linux-4.19.0-12-amd64",
"build_info": "(local build)",
"argv": [
"smartctl",
"-a",
"--json",
"/dev/nvme0"
],
"messages": [
{
"string": "Smartctl open device: /dev/nvme0 failed: Operation not permitted",
"severity": "error"
}
],
"exit_status": 2
}
}```
yah, this is due to the fact that this project only provides support for /dev/sda
.
I dont think we can provide support for the endless amount of possible mount points.
You might want either to fork this project and manipulate the config.json
to suit your needs or you could ask at homeassistant community if its possible to have the mount points for the addon being configured via UI.
The ability to specify a different hdd_path
than /dev/sda
is pointless if the config.json
does not ensure its being forwarded to the addon container.
Hello
nvme is the next generation of drives. Most of the new machines equipped with nvme drive. It could be good to be supported.
Anyway the addon has worked when I installed first...
Thx T
Sadly, homeassistant has changed permissions to devices. I have a NVMe aswell but its mounted as /dev/sda
.
@McGiverGim gave it a try to find a solution for non-/dev/sda
devices. Maybe he can give some advices.
Forking this repo and changing config.json
to install the fork via addon store in supervisor is still possible. But adding hundrets of mount points to the config.json
should be avoided.
I'd say, create a discourse thread at home assistant forums and ask for advices.
As this addon was initially designed for /dev/sda
devices while other mount points only worked due to the protection mode thing, this is nothing I want to approach.
This is free open source and no one is paid for anything. As already said in other issues: if you want stuff done, do it yourself or wait until some one else spends his free time to do so.
Reading again the configuration options of the addon, I think that if we remove the devices
mapping and we add again the full access
it will work.
Now that we have this repo working again, I can don this changes in my repo and let you try this @redskinhu if you want to test it.
I don't like to enable the full access
but if it works, is a possibility.
Sounds good, thanks.
Can you guide me how to test?
It's easy, add the addon from my own repo: https://github.com/McGiverGim/hassio-hdd-tools/
And disable de protection in Home Assistant:
I don't like to disable de protection, is always better to simply use de devices
tag to map it, but maybe is the best solution to support all.
NOTE: This is only a my test/develop repo, so it can change at any moment
Looking into internet, it seems we can maybe mount all the /dev
as device and disable the full_access
again... when you test the first solution, please report it here and, I will change my repo again with this solution to test it.
@McGiverGim Sounds good. How would that look like? I'm interested in this aswell as I have an addon which syncs backups to external USB Stick(s).
Looking more since my latest message, I think it will not work... docker let's mount volumes specifying the parent folder '/dev' only but what we want is to mount devices so the most probably is that it will not work.
The idea is to add a "devices": "/dev"
only in the config, but as I say, I think it will not work...
It would only work if we would pre-configure all possible mounts in the config.json
and as there are hundrets if not thousands of possible mount points (/dev/(nvme|sd[a-z])[0-9]?
), depending on the amount of devices attached to the system, this cannot be done.
It's easy, add the addon from my own repo: https://github.com/McGiverGim/hassio-hdd-tools/
And disable de protection in Home Assistant:
I don't like to disable de protection, is always better to simply use de
devices
tag to map it, but maybe is the best solution to support all.NOTE: This is only a my test/develop repo, so it can change at any moment
1st of all I'm not a programmer, so I have no clue what am I doing. ;-)
Thanks for the guide. (I thought it is much more complicated...)
I tried you repo, same issue. After I forked and changed the 2 sda in the config.json to nvme0 (I told I have no clue...) same issue:
It is complaining about:
Read NVMe Identify Controller failed: NVME_IOCTL_ADMIN_CMD: Permission denied
{
"json_format_version": [
1,
0
],
"smartctl": {
"version": [
7,
2
],
"svn_revision": "5155",
"platform_info": "x86_64-linux-4.19.0-12-amd64",
"build_info": "(local build)",
"argv": [
"smartctl",
"-a",
"--json",
"/dev/nvme0"
],
"messages": [
{
"string": "Read NVMe Identify Controller failed: NVME_IOCTL_ADMIN_CMD: Permission denied",
"severity": "error"
}
],
"exit_status": 2
},
"device": {
"name": "/dev/nvme0",
"info_name": "/dev/nvme0",
"type": "nvme",
"protocol": "NVMe"
}
}
So now I have stuck. I trying to sort this HDD temp sensor using different solutions about 2 yrs ago with no luck. But I'm optimistic because it is worked at least once.
You might want to use git on your homeassistant when connected via SSH.
Try the following:
ssh <user>@<ip of your homeassistant>
cd addons
git clone https://github.com/Draggon/hassio-hdd-tools.git
mv hassio-hdd-tools/hdd_tools .
rm -rf hassio-hdd-tools/
ls -d hdd_tools
Should output something like:
Cloning into 'hassio-hdd-tools'...
remote: Enumerating objects: 135, done.
remote: Counting objects: 100% (135/135), done.
remote: Compressing objects: 100% (94/94), done.
remote: Total 135 (delta 68), reused 99 (delta 41), pack-reused 0
Receiving objects: 100% (135/135), 34.08 KiB | 830.00 KiB/s, done.
Resolving deltas: 100% (68/68), done.
hdd_tools
After this, you can execute this to rename sda
to nvme
(NOTE: You might want to try nvme
, as nvme0
is just the partition but not the drive itself):
sed -i 's/sda/nvme/g' hdd_tools/config.json
Finally, you switch to your supervisor in homeassistant and hit reload.
In the end, the addon-store shows a Local add-ons
section above all other addons.
Switch to the addon, apply your configuration in the UI (target to /dev/nvme
) and start the addon.
Probably this might lead to a working solution.
Tried with nvme:
Smartctl open device: /dev/nvme failed: No such device
and nvme0:
"Smartctl open device: /dev/nvme0 failed: Operation not permitted"
The device is /dev/nvme0 and it have nvme0n1p1 nvme0n1p2 etc. partitions. And it is worked before with nvme0 settings, hence the error messages in the log, see the first post.
I installed the smartmontools to the host, and that is works fine with root priviledges
but without I got the same error message like before:
Smartctl open device: /dev/nvme0 failed: Permission denied
Other idea? Thanks for your effort.
I see. So the device is nvme0. Did you change the commands I've posted above to nvme0 instead? That didnt work?
Replace in the config file the "privileged": ["SYS_RAWIO"]
by "privileged": ["SYS_ADMIN"]
(or you can add both ["SYS_ADMIN","SYS_RAWIO"]
I think this will fix the NVME_IOCTL_ADMIN_CMD: Permission denied
but I don't know why it needs more permission for your nvme.
Looking for the error in Google, I have found this statement:
So it looks like --cap-add SYS_ADMIN is required for NVMe drives, but --cap-add SYS_RAWIO is enough for SATA/SCSI drives.
I'll try it this evening. Thanks
I've been doing some tests. I don't have and nvme disk, so waiting for confirmation of @redskinhu but this are the possibilities:
Current version, only works for /dev/sda
:
"devices": ["/dev/sda"],
"privileged": ["SYS_RAWIO"],
Problem: it does not work for /dev/nvme0
Add /dev/nvme0
to the list (waiting for confirmation that it works):
"devices": ["/dev/sda", "/dev/nvme0"],
"privileged": ["SYS_ADMIN", "SYS_RAWIO"],
Problem: we need to add other devices to the list if we found more. But maybe is an amount acceptable. At this moment I can imagine how many of them are...
Have a "common" list but add the full_access
too. This lets /dev/sda
and /dev/nvme0
work without removing the protection, but it can be removed by some user if he has some new /dev/xxx
until we add it to the list:
"devices": ["/dev/sda", "/dev/nvme0"],
"privileged": ["SYS_ADMIN", "SYS_RAWIO"],
"full_access": true,
Problem: The rating of the addon goes down from 4 to 1. Is not a problem, but it looks weird.
Yah, as I said, I would prefer having another way as adding thousands of possible mount points shouldn't be the solution. If we start adding one, we have to add more. Imho, its acceptable to manually checkout this repository and replace the addon as needed.
The problem with adding thousands of supported combinations will end in an heavy amount of maintanence.
Neither me nor you (@McGiverGim) have a NVME in place to test (I have, but mine is somehow mounted as /dev/sda
as its mounted via USB to my Raspberry Pi).
If you are fine with maintaining this, feel free to do so.
For me, keeping focus on /dev/sda
is focused and in case I can help others to make it work for their setups, I'm here happy to help. But I'd rather not add more devices to the list unless there is a generic way to do so.
I canged sda
to nvme0
and SYS_RAWIO
to SYS_ADMIN
and I have the long awaited sensor value.
Megathanks!
I wonder if that would work when we add SYS_ADMIN
to the config aswell.
does it work without full_access
? 🤔
It's easy. For /dev/sda
we need SYS_RAWIO
, for /dev/nvme0
we need SYS_ADMIN
. If we don't add this, the full_access
does not work.
Apart of this, we can add the device to the devices
list or enable the full_access
, what we prefer.
We don't know how many mount points exist, so I think the final "easy" solution is to add the more standard ones to the devices list, and add the full_access
too to being used for people with more "exotic" devices.
It's clear that /dev/sda
is the more common device. I don't know if /dev/nvme0
is the habitual device for nvme drives, but looking into internet it seems that yes.
@boesing if it's ok, I can push a PR with:
"devices": ["/dev/sda", "/dev/nvme0"],
"privileged": ["SYS_ADMIN", "SYS_RAWIO"],
"full_access": true,
that will let work the habitual sda and the nvme devices, that are the major part of actual configurations, without disabling the addon protection. For the others we let disable it and it will work, I will indicate it too in the documentation when doing the PR.
It's ok for you? The only drawback is the rating of the addon, it will go from 4 to 1, but I think is necessary to make this work for everybody.
mh, lowering the rating seems weird to end users tbh. It worked for them with a higher rating tho.
I dont think this would be a good move just to provide support for yet 1 consumer. I am not the owner of this repository and dont want to act like one. @Draggon are you still consuming your own addon? Do you have thoughts on this?
Until my latest commits, it was the score of the addon, 1, because it was mandatory to have the full access. With my latest changes is not, but only /dev/sda can be mounted.
nvme devices are very popular now, the difference is that if we have a raspberry pi or similar, connected by USB, it will be a /dev/sda device, but if we have a docker or similar connected to a real device with a real nvme, we will have /dev/nvme0.
sure then. if we are resetting Score back to the initial one, why not.
Hello
I have NVMe disk (/dev/nvme0) in the HASS server.
I installed this add-on, but I get error message when it starts: Device /dev/nvme0 not found - exiting And the add-on is looks stopped, but it puts the sensor value to the HASS.
update: couple of minutes later I went back to the add-on Info page and now it looks the add-on is running.
Is this the way how is this add-on working? The log is very misguiding...
Thanks for advance
Detailed log:
Home Assistant Supervisor
host_os | Debian GNU/Linux 10 (buster) -- | -- update_channel | stable supervisor_version | supervisor-2021.02.6 docker_version | 19.03.13 disk_total | 201.9 GB disk_used | 134.3 GB healthy | true supported | true supervisor_api | ok version_api | ok installed_addons | Samba share (9.3.0), Portainer (1.4.0), UniFi Controller (0.20.2), Duck DNS (1.12.4), Node-RED (8.1.1), Log Viewer (0.9.1), ESPHome (1.16.0), MariaDB (2.2.1), phpMyAdmin (0.2.0), WireGuard (0.4.0), Traccar (0.11.0), Folding@home (0.2.0), DHCP server (1.2), Bookstack (0.8.2), Bitwarden RS (0.8.0), Tor (3.0.2), APC UPS Daemon (No USB) (1.9), AdGuard Home (3.0.0), Visual Studio Code (3.0.3), Network UPS Tools (0.5.0), Mosquitto broker (5.1), motionEye (0.11.0)