EdgarWallace

I was trying to migrate from openHAB running in an Ubuntu VM to this Docker. I am using the standard template (br0) but I can‘t reach the KNX bus. Is net=Host required?

Great @bonienl Worked very well, thank you very much: root@Tower:~# /usr/local/emhttp/plugins/dynamix.file.integrity/scripts/bunker -b2 -u "/mnt/disk2/iTunes/Music/Eric Clapton/I Still Do" Finished - verified 12 files, skipped 0 files. Found: 0 mismatches, 1 corruption (updated). Duration: 00:00:04. Average speed: 149 MB/s

Oh great@bonienl. Thanks a lot. Gesendet von iPad mit Tapatalk

On every run the server is providing a wrong error message: BLAKE2 hash key mismatch, /mnt/disk5/iTunes/Music/Wolfgang Haffner/Kind of Cool/02 So What.aif is corrupted However the file is perfectly ok. Is there any way to update the hash key manually?

Thanks a lot for your clarification @aptalca Making sure that I am leaving my server on during the night from time to time.

@aptalca, yes I am usually shutting it down. I was hoping that the renewal is also running, when the container is starting.

@trurl, thanks for your help in moving that into the correct thread. @saarg, I have never modified anything within the container because it was running as expected - until March 1st. I read, that letsencrypt is producing these file one after one e.g. /mnt/user/system/docker/appdata/letsencrypt/etc/letsencrypt/live/myurl.com/cert.pem is pointing towards the correct file in /mnt/user/system/docker/appdata/letsencrypt/etc/letsencrypt/archive/myurl.com/cert7.pem so having many of these files seems to be fine. I was asking mainly if there is a known issue with the container, because the log it isn't showing anything unusual. However, I might have overlooked something so it is attached now. Thanks for your help.

Thanks a lot @saarg I don't understand why the certificate wasn't renewed this time (March 1s). It was always working in the past. E.g. cert1.pem - cert6.pem are available in the respective directory but cert7.pem was missing and added with my manual action. Subdomain was always defined as (no changes from my side were made since ages): , I am using this container only for Nextcloud and I am accessing it via https://myurl.com/index.php/login

I fixed my issue with: open console of letsencrypt container run command: certbot renew First time ever letsencrypt wasn't doing the certificate renewal process automatically. Anyone has experienced the same? Is there anything I can do about it?

Seems that Let's Encrypt didn't renew the certificate. I was searching but didn't found anything that is showing how to solve that renewal issue. Any hint?

I am having well running Nextcloud and Let's Encrypt Docker (log is saying: [services.d] done and Server ready). On March 1st the SSL Certificate was loosing validity and now all my devices (macos, iphone, iPad) can't access Nextcloud anymore. After done some search I thought that I have to download the renewed key at /mnt/user/system/docker/appdata/letsencrypt/keys/letsencrypt There are a couple of keys (cert.pem, fullchain.pem etc.) that are linked to e.g. /mnt/user/system/docker/appdata/letsencrypt/etc/letsencrypt/archive/myURL/cert.pem Whatever file I am loading into one of my devices it is telling me that it was loosing validity March 1st. Thanks for any help.

I am having well running Nextcloud and Let's Encrypt Docker (log is saying: [services.d] done and Server ready). On March 1st the SSL Certificate was losing validity and now all my devices (macos, iphone, iPad) can't access Nextcloud anymore. After done some search I thought that I have to download the renewed key at /mnt/user/system/docker/appdata/letsencrypt/keys/letsencrypt There are a couple of keys (cert.pem, fullchain.pem etc.) that are linked to e.g. /mnt/user/system/docker/appdata/letsencrypt/etc/letsencrypt/archive/myURL/cert.pem Whatever file I am loading into one of my devices it is telling me that it was loosing validity March 1st. Thanks for any help,

The upgrade went well on both of my servers. I love that all my Macs are running Time Machine now via SMB.

Yes, the Fan Speed Mode will be kept forever....my settings are shown below.

I was looking into the file system of my Selfsat device. It is basically a Linux device and there is no such a file. I honestly don‘t know what happened because it was working until any of the TVheadend updates.

My main server contains a X11SSL-CF board. IPMI was running very well but since a while the Fan Speed Mode is set at FULL. Hence my fans are running at full speed and only if I am setting it back to Standard or Optimal, IPMI plugin is taking back control and the fans are running at much lower speed. BIOS version is 2.2 from 05/23/18, Firmware is 1.48 from 06/22/18, Redfish 1.0.1 Maybe I overlooked something during the recent IPMI updates?

Well, I did all may home work and even updated my Selfsat device. According to this site the correct RUN_OPT should be: --satip_xml http://192.168.178.30:8000 However, doesn't work for me. TVheadend even doesn't show anything under DVB Input.

Thanks @alturismo According to my search engine of choice you are using a Fritz!Box? The port of my Selfsat dish/sat>ip server is; 8000 Using your example: 2019-02-26 18:59:05.103 [ ERROR] satip: Cannot get http://192.168.178.30:49000/satipdesc.xml: Connection refused Using port 8000: 2019-02-26 19:01:49.576 [ ERROR] satip: Cannot get http://192.168.178.30:8000/satipdesc.xml: No such file or directory Seems that port 8000 is correct but how do I get the xml file?

root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='tvheadend' --net='host' --log-opt max-size='10m' --log-opt max-file='1' --privileged=true -e TZ="Europe/Berlin" -e HOST_OS="Unraid" -e 'TCP_PORT_9981'='9981' -e 'TCP_PORT_9983'='9983' -e 'PGID'='100' -e 'PUID'='99' -v '/mnt/cache/system/docker/appdata/tvheadend/':'/config':'rw' -v '/mnt/user/Recordings/':'/recordings':'rw' --satip_xml 192.168.178.30 'linuxserver/tvheadend' unknown flag: --satip_xml See 'docker run --help'. The command failed. Thanks @saarg the message appears when I am adding --satip_xml 192.168.178.30 which is the selfsat ip address.

Thanks to @j0nnymoe and @alturismo I was running tvheadend always in host mode and I have removed the DVB Edition. How do I remove the -p flag? The docker is pulling the wrong IP address. 192.168.178.28 is the server address, the sat>ip address is 192.168.178.30. Adding --satip_binaddr into Extra Parameters is causing a docker crash. 2019-02-26 10:06:08.656 [ INFO] main: Log started 2019-02-26 10:06:08.656 [ INFO] http: Starting HTTP server 0.0.0.0:9981 2019-02-26 10:06:08.656 [ INFO] htsp: Starting HTSP server 0.0.0.0:9982 2019-02-26 10:06:08.656 [ ERROR] satips: use --satip_bindaddr parameter to select the local IP for SAT>IP 2019-02-26 10:06:08.656 [ ERROR] satips: using Google lookup (might block the task until timeout) 2019-02-26 10:06:08.674 [ INFO] satips: Starting SAT>IP RTSP server 192.168.178.28:9983 2019-02-26 10:06:08.674 [ INFO] satips: SAT>IP Server initialized 2019-02-26 10:06:08.674 [ INFO] satips: HTTP 192.168.178.28:9981, RTSP 192.168.178.28:9983

It is a Selfsat antenna which has the Satip server imbedded. Question is how to pass through the satip ip address.

I would like to pass my SAT>IP Server to the TVHEADEND docker. unRAID DVB is showing no DVB Adapter Driver, is this the reason, why I don't see any TV Adapter in TVHeadend docker? Do I need unRAID DVB at all? I was trying to use --satip_bindaddr in Extra Parameter but this avoid Docker start. Here is my log: https://pastebin.com/GhN8WSt7 Any great ideas how to use my sat>ip server with TVHeadend? Thank you very much.

Since the last Nextcloud update (Nextcloud 13.0.2) it's complaining about some security issues I have added via my config settings: Der „X-XSS-Protection“-HTTP-Header ist nicht so konfiguriert, dass er „1; mode=block“ entspricht. Der „X-Content-Type-Options“-HTTP-Header ist nicht so konfiguriert, dass er „nosniff“ entspricht. Der „X-Robots-Tag“-HTTP-Header ist nicht so konfiguriert, dass er „none“ entspricht. Der „X-Download-Options“-HTTP-Header ist nicht so konfiguriert, dass er „noopen“ entspricht. Der „X-Permitted-Cross-Domain-Policies“-HTTP-Header ist nicht so konfiguriert, dass er „none“ entspricht. However, the default file is showing the correct settings: Anyone can guide me towards a solution? Thanks a lot.

I corrected according to your advise and the shutdown went fine yesterday. This should be visible from the diagnostics below. Cross fingers that the issue is gone. Thanks again @dlandon tower-diagnostics-20180424-2331.zip

The is great advise @dlandon as I had several unclean shutdown's in the past weeks (when I tried to shutdown either via Main/Array Operation/PowerDown or via Dynamix System Buttons). I followed your advise and have modified these settings: Settings->VM Manager->VM Shutdown time-out 300 seconds Settings->Disk Settings->Shutdown time-out 420 seconds Tips and Tweaks plugin: Processes to kill before Array is Stopped: ssh, bash Here is the diagnostics from yesterday....I can't see that anything from the 3 new settings were preventing my array to shutdown but someone smarter than me might identify the root cause. Thanks a lot.