CHBMB

How are you reverse proxying it?

For the warnings then delete the `default` file and it will be recreated on container restart. Alternatively take a look at the version on Github.

That's the sort of thing you really should write up so others can benefit from

No, otherwise I'd have posted something here..... @BRiT You're like Sherlock Holmes

I don't think we need them, if it were a widespread issue, we'd have heard by now. As it stands a solitary report I don't think justifies a conclusion of the container logic not handling things well. If the API/certbot had an issue, no amount of rewriting of the container is going to fix that.

Assuming you're using the TBS build yeah? Unfortunately there's nothing I can do or reconfigure for this, as TBS is it's own separate tree unlike the LibreELEC one which I do need to select things. Your card should be supported according to the wiki here. https://github.com/tbsdtv/linux_media/wiki

Might help if you posted in either the support thread for the applications you're trying to run. You haven't changed the port number from within the Radarr or Sonarr webui have you? Cos that will definitely break stuff.

Doesn't build currently on RC6, I think something has changed in the bzroot packaging, as I can reproduce the error merely by unpacking and repacking the stock Unraid bzroot, have messaged @limetech for some advice.

Yeah, you don't need to install drivers on Unraid, so you could use the Nvidia plugin if you wanted. Sent from my Mi A1 using Tapatalk

You could run Sat-IP on the Raspbian and then tvheadend on Unraid. Sat-IP would turn your Pi into a network tuner. Sent from my Mi A1 using Tapatalk

I understand you don't want to compile yourself, but I don't particularly want to compile any more than the exisiting four/five builds I do with every release. If these kernel modifications are needed then they should be pushed upstream to LimeTech.

Reading the article it sounds like a previously known vulnerability is used to implement the malware. We've already patched it and posted on our blog about it. https://blog.linuxserver.io/2019/10/26/psa-nextcloud/ I suggest you all read that and implement, this does highlight one point I've been making for a long time, once you spin up these services, whether you understand how to or not, you become the sysadmin and need to be able to keep things up to date. TL:DR I think it's using a known vulnerability to encrypt things, but that hasn't been confirmed yet, so you need to decide on how you want to approach this issue and when you feel the risk is acceptable to keep/bring back your Nextcloud server online. Sent from my Mi A1 using Tapatalk

No idea. Sent from my Mi A1 using Tapatalk

Can;t tell you exactly what the problem is but this is probably relevant. https://serverfault.com/a/396847 I'd recheck your config, I suspect you've missed a setting that is incorrect.

Check your /config/nginx/logs/ folder to see what that says. That IO error is a bit concerning, makes me wonder if your appdata has become a bit corrupted.

Logs for why the connection is failing would be my first suggestion. Otherwise not much to go on.

docker exec -it habridge apk add openssh-client will install it, it won't survive a container update. You could look at this to install it at container startup time https://blog.linuxserver.io/2019/09/14/customizing-our-containers/

V6.8.0rc5 done Sent from my Mi A1 using Tapatalk

V6.8.0rc5 done Sent from my Mi A1 using Tapatalk

v6.8.0rc4 uploaded still no CrazyCat

v6.8.0rc4 uploaded

See the link in the first post on how to update the container, in that post it shows you how to run occ Sent from my Mi A1 using Tapatalk

Here's a diff between testparm -sv output on v6.7.2 and v6.8.0rc3 chbmb@thinkpad:~/Downloads$ diff testparm-v6.7.2 testparm-v6.8.0rc3 38c38 < client min protocol = CORE --- > client min protocol = SMB2_02 57c57 < deadtime = 0 --- > deadtime = 10080 58a59 > debug encryption = No 143c144 < log level = 2 --- > log level = 1 207c208,210 < prefork children = 1 --- > prefork backoff increment = 10 > prefork children = 4 > prefork maximum backoff = 120 232c235 < server min protocol = LANMAN1 --- > server min protocol = SMB2_02 289d291 < web port = 901 369a372 > hide new files timeout = 0 390c393 < mangled names = yes --- > mangled names = illegal 426a430,433 > smbd async dosmode = No > smbd getinfo ask sharemode = Yes > smbd max async dosmode = 0 > smbd search ask sharemode = Yes testparm-v6.7.2 testparm-v6.8.0rc3

Just to add my tuppence worth to this. I run Ubuntu on my desktop and with rc3 I am unable to see any of my Unraid machines on the LAN in my file browser, tried a few different file managers on my laptop, didn't make any difference at all, tried altering my SMB settings in Unraid, again didn't make a difference at all, downgraded to 6.7.2 and my machines reappear on the network browser in my file manager. However even on rc3 I was able to browse my network shares by addressing them directly in the file manager with smb://192.168.0.100/$share or smb://matrix/$share So I think that this all points to an issue with smb. I have one machine with netbios enabled and one without netbios enabled to test. Both are discoverable on v6.7.2 neither are discoverable on rc1/rc3. My main machine is the local master via the Dynamix Local Master plugin. EDIT: Actually when I've written rc1, I should have written v6.7.2, dunno what I was thinking. Have edited my post to reflect this.

Can keep a track on things here https://status.digitalocean.com/incidents/sb6p4w9ksqlg?u=d1yxkjzvvdxr