b0m541

The issue with being unable to mount remote shares if DNS domain names are used for the server has been fixed in 2020.11.25a. @dlandon Thank you for the quick solution! Great responsiveness!

None of the external programs such as ffmpeg or ebook-convert seem to some with the container or are not properly set up. Am I missing the point of using containers here? Why would those program names be pre-configured, but the programs are missing?

It definitely must be the DNS name handling. When I use the IP of the server, it does work. The DNS resolution does work on unraid using ping. forward and reverse zone are properly set up. One note: the servername I had used is a CNAME / alias. The reverse lookup of that IP is a different DNS name. I tried with the A record name instead of the CNAME. The online check does also fail. PS: I am quite sure that for diagnosing that, the diagnostics would have been of no big help.

Sorry, you asked for a screenshot So the names are as follows: Source: //servername.subnet.tld/foldername Mountpoint: SERVERNAME.SUBNET.TLD_foldername servername small caps, including alphanumeric characters and "-" dash all other components: small caps alphabetic characters How does the online test work? ping servername.subnet.tld shows that ICMP ECHO works. Also mounting the share manually on unraid does work without problems.

Sure, knock yourself out: The share is mountable on other machines, there are no additional firewall filters for the unraid host. The mount point name is the one generated by the plugin.

This is not about any particular file in itself. The whole set in itself is deanonymzing you 100%. Every setup described in that detail is unique. Some of the files would be sufficient to verify the dataset against a given setup, as e.g. the combination of hardware drive names in use.

I saw that they are anonymized, I looked at them, and my concerns are still there. The concept to post a complete set of diagnostics data publicly for anyone to read who desires to me is conflicting with the concept of data thriftyness. A request to Limetech will not resolve that conflict. I honestly doubt that all that data will be necessary to actually find why the mount will not work. I would assume it is also in your interest if users are willing to look into the problem on their own. So if you let them know, where to look, where is the harm? I understand that it will be a bit more effort on each side, but privacy has often a cost after all.

Oh I see. No offense, that data is super privacy invasive and I do care about that. Please let me know what exact files you need to see where the problem is, I might then as well be able to understand the problem on my own.

Wow that was fast. where to find the shares diagnostics?

Mounting remote SMB shares does not work for me in version 2020.11.23b I can create an entry fine, and while doing that it will show the available shares. After the entry is created the "mount" button is greyed out and cannot be clicked. I did not find any messages relating that in the regular log files, maybe I looked in the wrong location. This is a rather urgent topic for me, since I have several containers who use remote shares.

Hey guys, I have a problem with the unifi controller that I cannot figure out and fix on my own. I had the latest branch container running. The whole thing started with an UAP AC Mesh that was connected using mesh to a wired UAP becoming disconnected and when power-cycled not being able to get connected again. I then wired that UAP AC Mesh to the subnet where the controller and all unifi components are wired. A reset and even a factory reset resulted in the UAP AC Mesh being shown as "Adopting" in the controller but not making any progress. I then realized that UDP port 10001 was not showing in the docker port mappings and experimented with removing port mappings from the Controller container, but after starting the containers the mappings still were there. I could not find an explanation for the UDP 10001 mapping being missing (also after re-installation) or removed mappings still being shown. So I re-installed the container from scratch with default mappings. After that the container would start, but the UI would _not_ work any more. So I tried the branches 5.9 and 5.8 but none of that worked. Also restarting Docker or the server would not help! Its saying "UniFi Controller is starting up... Please wait a moment" So now I am stuck with a non-working cointainer! (I do have a backup the the "latest" appdata, but my appdata backup folder got somehow wiped - of course when it is needed. But the are: unifi-controller/data/backup/5.14.23.unf unifi-controller/data/backup/6.0.20.unf unifi-controller/data/backup/6.0.22.unf) So I guess I should be able to roll back to 5.14.23. The UAP AC Mesh (default login) shows: Status: Unknown[11] (http://"controller-ip":8080/inform) which looks fine Any help is welcome!

This may be normal for this container, I wouldn't call it optimal. So you are right, the logs count against "Writable" instead of "Log", and actually the logs should be placed in the log folder on appdata... But hey, you get what you pay for and thanks for your help.

I am wondering, are there no others using SNMP to monitor /manage their UPS? Is nobody else having this problem? If so, there must be a way to do it right / better, an I would like to learn how. Is nobody currently maintaining the NUT plugin?

Is it normal that the UNMS container is so bloated? unms container: 3.67 GB writable: 1.81 GB log: 28.2 MB If not, what can I do to get it back to normal?

That did work as long as 5.8 was part of current. Now current comes with 5.9 and the libnetsnmp is 40, not 35. This does not work with the NUT 2020 05 plugin, which expects 35. Unfortunately NONE of the slackware64 release has libnetsnmp 35! I guess we really need a sustainable solution now. Any ideas?

Is it normal that no data points are exported whole the UPS is running on battery? It does only export data point while the UPS is on line input. This is what the debug log gives: [DEBUG] http://localhost:8086 "POST /write?db=nut HTTP/1.1" 400 156 Traceback (most recent call last): File "/src/nut-influxdb-exporter.py", line 113, in <module> print(client.write_points(json_body)) File "/usr/local/lib/python3.8/site-packages/influxdb/client.py", line 594, in write_points return self._write_points(points=points, File "/usr/local/lib/python3.8/site-packages/influxdb/client.py", line 672, in _write_points self.write( File "/usr/local/lib/python3.8/site-packages/influxdb/client.py", line 404, in write self.request( File "/usr/local/lib/python3.8/site-packages/influxdb/client.py", line 369, in request raise InfluxDBClientError(err_msg, response.status_code) influxdb.exceptions.InfluxDBClientError: 400: {"error":"partial write: field type conflict: input field \"input.voltage\" on measurement \"ups_status\" is type integer, already exists as type float dropped=1"} Error connecting to InfluxDB. Looks to me like the exporter wants to write as integer if NUT provides no decimal point for a measurement that at other times contains a decimal point (this is the case for voltage, and when running on battery NUT measures as voltage 0 instead of 0.0). I would suggest to cast all numerical measurements that main contain a decimal point always to float and not letting the interpreter decide the variable type automatically. As a fix i just removed to conversion to integer -> no more errors in the log: def convert_to_type(s): """ A function to convert a str to either integer or float. If neither, it will return the str. """ try: float_var = float(s) return float_var except ValueError: return s

Connecting to InfluxDB host:xyz, DB:nut Connected successfully to InfluxDB Connecting to NUT host xyz:3493 Connected successfully to NUT Error connecting to InfluxDB. The same with DEBUG on: [DEBUG] http://localhost:8086 "POST /write?db=nut HTTP/1.1" 400 158 Traceback (most recent call last): File "/src/nut-influxdb-exporter.py", line 113, in <module> print(client.write_points(json_body)) File "/usr/local/lib/python3.8/site-packages/influxdb/client.py", line 594, in write_points return self._write_points(points=points, File "/usr/local/lib/python3.8/site-packages/influxdb/client.py", line 672, in _write_points self.write( File "/usr/local/lib/python3.8/site-packages/influxdb/client.py", line 404, in write self.request( File "/usr/local/lib/python3.8/site-packages/influxdb/client.py", line 369, in request raise InfluxDBClientError(err_msg, response.status_code) influxdb.exceptions.InfluxDBClientError: 400: {"error":"partial write: field type conflict: input field \"ups.temperature\" on measurement \"ups_status\" is type integer, already exists as type float dropped=1"} Error connecting to InfluxDB. The nut-influxdb-exporter container log is full of these. The problem is that there are long time periods during which no values are written by the exporter into influxbd. The curious thing is, that in the influxdb log I see frequent periodic POSTs of the exporter! [httpd] 172.17.0.1 - nut-unraid [02/Aug/2020:15:23:29 +0200] "POST /write?db=nut HTTP/1.1" 400 156 "-" "python-requests/2.23.0" 5b11b2e5-d4c3-11ea-acab-0242ac110003 9191 ts=2020-08-02T13:23:40.173464Z lvl=info msg="Executing query" log_id=0ONPV9xl000 service=query query="CREATE DATABASE nut" [httpd] 172.17.0.1 - nut-unraid [02/Aug/2020:15:23:40 +0200] "POST /query?db=nut&q=CREATE+DATABASE+%22nut%22 HTTP/1.1" 200 58 "-" "python-requests/2.23.0" 6124c50e-d4c3-11ea-acaf-0242ac110003 408 [httpd] 172.17.0.1 - nut-unraid [02/Aug/2020:15:23:40 +0200] "POST /write?db=nut HTTP/1.1" 400 156 "-" "python-requests/2.23.0" 612bbc82-d4c3-11ea-acb0-0242ac110003 7150 [httpd] 172.17.0.1 - nut-unraid [02/Aug/2020:15:23:50 +0200] "POST /query?db=nut&q=CREATE+DATABASE+%22nut%22 HTTP/1.1" 200 58 "-" "python-requests/2.23.0" 67398c3a-d4c3-11ea-acb5-0242ac110003 364 [httpd] 172.17.0.1 - nut-unraid [02/Aug/2020:15:23:50 +0200] "POST /write?db=nut HTTP/1.1" 400 156 "-" "python-requests/2.23.0" 67408967-d4c3-11ea-acb6-0242ac110003 8965 [httpd] 172.17.0.1 - nut-unraid [02/Aug/2020:15:24:10 +0200] "POST /query?db=nut&q=CREATE+DATABASE+%22nut%22 HTTP/1.1" 200 58 "-" "python-requests/2.23.0" 736c2a5c-d4c3-11ea-acc3-0242ac110003 352 [httpd] 172.17.0.1 - nut-unraid [02/Aug/2020:15:24:10 +0200] "POST /write and so on... For the fix see the next two postings.

[myups] driver = snmp-ups port = <myups-ip> snmp_version = v3 secLevel = "authPriv" secName = "mysnmpuser" authProtocol = "MD5" privProtocol = "DES" authPassword = "myauthpw" privPassword = "mycryptpw" pollfreq = 15 I have SNMPv3 working fine with MD5 and DES. Unfortunately both algorithm today are not considered sufficiently secure. So I would like to replace MD5 with SHA and DES with AES. My UPS supports MD5 and AES fine which I can test using snmpwalk. Unfortunately when I use authProtocol = "SHA" privProtocol = "AES" NUT will not start and claims to not find a suitable device. Any ideas how to fix this?

OK, got it. Lets say I wanted to have a swap file of 128GB, just in case... What is the recommended route to go? Put swap on HDD oder SSD? For that I would need to reformat a drive or the cache pool from BTRFS to XFS. If the best way would be to take the cache SSD pool from BTRFS to XFS, what is the recommended strategy to get from a) to b)? Note: I have empty drives lingering in the array, would be easy to reformat one from BTRFS to XFS, but I guess putting swap on the cache pool is better?

I just realize that my unraid machine does not have swap enabled. I did not find much information here in the forum. Does unraid by default use a swap file or do I need to enable that manually somewhere? Of course, I can do it using this plugin, I am just wondering if there is a standard mechanism in the unRAID UI for swap and I just didn't find it.. I also found that swap files are not supported on BTRFS on Linux earlier than version 5, which is a pity, because all my drives use BTRFS, also the SSD Cache drives. I never had memory problems, but with recently more docker containers, some of which use a a few hundred MB RAM, I seem to reach a limit, CPU and Storage get very busy when memory fills up. I first thought that this is caused by swap thrashing, and then saw that the machine does not use swap at all.... What is the recommended route to go? Put swap on HDD oder SSD? For that I would need to reformat a drive or the cache pool from BTRFS to XFS. Am I overthinking this? Will unraid select the best location and create a swap file when it finds a non-BTRFS formatted drive? If the best way would be to take the cache SSD pool from BTRFS to XFS, what is the recommended strategy to get from a) to b)? Note: I have empty drives lingering in the array, would be easy to reformat one from BTRFS to XFS, but I guess putting swap on the cache pool is better?

I have problems with a container (dockerhub conversion?) so I removed it. When I look this container up in CA and re-install it, the docket template uses all the values I previously had used. That is useful most of the time, but in this case I want to start fresh. How can I make CA or unraid to use the docker template as it is in CA, and not what I had changed later? Also how can I remove templates from the selection list where unraid collects all templates I ever used (this list is shown when you click "Add container" on the docker page in unraid)

I have been running this container for quite a while, never any problems. Until I started using VMs on unraid. The VM manger seems to have its own DHCP server and possibly name server. It starts before the pihole container and when pihole tries to bind port 67 (DHCP), it fails because the VM manager is already binding it to 0.0.0.0 what solutions are viable? (except for not using VMs, I need that feature now)

Is any body lucky using Mapquest for Day/Night ? Mapquest makes it easiest to get an account and an API key. However, unfortunately I always get "No geographical coordinates found for the given address. Please adjust.", no matter what address I put in. Somebody luckier with MapQuest? Maybe this is the reason: Mapquest seems to be really bad at locating addresses outside of the US. PS: Bing did work but it was a lot more effort to get an account.

Check this video out. It explains what you can do. https://www.youtube.com/watch?v=aAh8_8u-Zw0 However, the Hassio container solution seems not be be stable in the long run. Check out this thread: https://community.home-assistant.io/t/hassio-on-unraid/59959/144 If you want HASSio in a VM, look at this video: https://www.youtube.com/watch?v=BbzZjnCSEjs

I think the problem is that it cannot install HA: [supervisor.docker.interface] Update image homeassistant/intel-nuc-homeassistant:landingpage to homeassistant/-homeassistant:0.108.6[0m [32m20-04-18 20:59:40 INFO (SyncWorker_9) [supervisor.docker.interface] Pull image homeassistant/-homeassistant tag 0.108.6.[0m [31m20-04-18 20:59:40 ERROR (SyncWorker_9) [supervisor.docker.interface] Can't install homeassistant/-homeassistant:0.108.6 -> 400 Client Error: Bad Request ("invalid reference format").[0m [33m20-04-18 20:59:40 WARNING (MainThread) [supervisor.homeassistant] Error on install Home Assistant. Retry in 30sec[0m I already replaced homeassistant/intel-nuc-homeassistant with homeassistant/home-assistant but that did not work either. Any ideas?