archedraft

After rereading the upgrade notes, I noticed that Host access to custom networks was set to disabled in docker settings and it seemed like if you are using macvlan you probably want it enabled. I enabled it and now I have local network access via Wireguard. No exactly sure why a docker setting would effect the wireguard network but hey it's working again... For anyone who knows more about this, feel free to share the knowledge.

Hey All, been awhile! I recently updated my server to 6.12.6 and got a message from "Fix Common Problems" that macvlan and bridging on should be corrected. From what I was reading, I left the docker setting with macvlan and I turned off bonding and bridging. I restarted the system and the error message went away. My dockers appear to be working correctly. I went to use Wireguard today and I can connect and access the unRAID web gui but I no longer have access to my local network; whereas, yesterday everything was working fine. I must have messed up something with the network changes. Do I need to recreate the wireguard network now that I updated the unRAID network? or should I change the docker macvlan to ipvlan and turn back on bonding and bridging?

Reading the documentation is helpful Manual/Security - Unraid | Docs Redirects When accessing http://[ipaddress] or http://[servername].[localTLD] , the behavior will change depending on the value of the Use SSL/TLS setting: If Use SSL/TLS is set to Strict, you will be redirected to https://[lan-ip].[hash].myunraid.net However, this behavior makes it more difficult to access your server when DNS is unavailable (i.e. your Internet goes down). If that happens see the note under Https with Unraid.net certificate - with no fallback URL If Use SSL/TLS is set to Yes, you will be redirected to https://[ipaddress] or https://[servername].[localTLD] as that will likely work even if your Internet goes down. If Use SSL/TLS is set to No, then the http url will load directly. Note: for the redirects to work, you must start from http urls not https urls.

Updated to 6.10 today from 6.9 - When I first typed the servers IP address it told me it was not secured. In 6.9 it used to redirect the IP to the long string of numbers and letters followed by .unraid.net. I saw that the new cert added wildcards so I updated my cert and then changed my pfSense DNS resolver from unraid.net to myunraid.net server: private-domain: "myunraid.net" If I click on the Certificate subject blue link under Management Access I can log into unRAID through that address and it is secure. If I type in my ip address it doesn't redirect me though. Is that no longer an option or is there another setting I am missing?

I appreciate the link. Thank you.

Is there anyway to get PhotoPrism to auto scan the photo folder for new photos and add them?

Does Nextcloud compress images from the phone when it uploads them? The same pictures that get auto uploaded via Dropbox are 2-3x larger than the ones from the Nextcloud app.

Hey guys, I am wanting to use External Storages to link an unRAID share into NC. I have read through here that you can do this either by "local" if I pass through the parameters in the docker settings or "SMB / CIFS" which seems to be preferred so that the folder permissions are respected. My issue, is that my NC docker is on a custom br0 network with a fixed ip address so that I could give letsencrypt that ip address. Since NC is on the br0 network, I am unable to ping my unRAID ip address from within the NC docker and thus I am unable to connect to my unRAID share. Does anyone know of a way to allow NC to see my unRAID ip? EDIT: Another interesting development, I can ping any other device on my local network from within the NC docker, expect my unRAID ip... hmmm EDIT #2: As it turns out, it was not an interesting development that i could not access my unRAID ip. It is very well documented that this is by design. Anyway, I decided I would just test out using the local option and it appears to be working just fine.

Woot! Thanks for your help! Also, I am ashamed that it is 2019 and as of this morning I was still on v12...

I was chuckling about exactly this the other day! But hey it’s a scary place out there...

Another uneventful update... THANKS! 😁 Those are the best kinds. Dashboard is looking great.

Maybe I can offer a different perspective. First let’s go to the “1,000 foot bird eye view” and ask the question what are we trying to accomplish? Likely the answer is to protect data. The next question is what are you willing to do to protect said data? Well, we built a dedicated computer to store our important files. So we are going above and beyond what most “common” folks do to store files. When you start adding up the money spent on the computer hardware plus the actual storage drives, there is some serious money invested. I think if you look at it in that regard, and ask the question is my data worth an extra $100 dollars for a piece of hardware that is known to work great and let’s me stay on up to date software that comes with the latest security patches or is it worth it to use a piece of hardware with known issues that will likely not get better... well I know what my decision would be. Anyways just something to think about.

This happened on all my custom networked (br0) dockers. I edited to network on each one to bridge and let it reconfigure itself and changed it back to custom (br0) and they are back up and running.

For anyone wondering the answer is yes! I had to edit my let's encrypt config and made "blueiris" a sub domain. As soon as I changed that it started working immediately. I was also able to close my stunnel port forwarding rule in my router! Let's Encrypt is pretty cool stuff. 😎 server { listen 443 ssl; root /config/www; index index.html index.htm index.php; server_name blueiris.random.server.name.org; ssl_certificate /config/keys/letsencrypt/fullchain.pem; ssl_certificate_key /config/keys/letsencrypt/privkey.pem; ssl_dhparam /config/nginx/dhparams.pem; ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA'; ssl_prefer_server_ciphers on; client_max_body_size 0; location / { include /config/nginx/proxy.conf; proxy_pass https://192.168.1.100:8777; # NOTE: Port 8777 is the stunnel port number and not the blue iris http port number } }

Has anyone had any luck setting up Let's Encrypt to work with Blue Iris and Stunnel? I currently have Blue Iris and Stunnel working together (meaning I can port forward my stunnel port in my router and stunnel will redirect to the Blue Iris port, thus giving https). I was hoping to setup Let's Encrypt to work with Stunnel in order to use Let's Encrypts 443 port and close the Stunnel port to the world. I have Let's Encrypt successfully working with Nextcloud. The next cloud config file is "letsencrypt\nginx\site-confs\nextcloud". I was thinking that all I would have to do is copy the nextcloud config and rename it as follows: "letsencrypt\nginx\site-confs\blueiris" and I changed the new blue iris config to as follows: server { listen 443 ssl; server_name fake.archedraft.server.name.org; root /config/www; index index.html index.htm index.php; ###SSL Certificates ssl_certificate /config/keys/letsencrypt/fullchain.pem; ssl_certificate_key /config/keys/letsencrypt/privkey.pem; ###Diffie–Hellman key exchange ### ssl_dhparam /config/nginx/dhparams.pem; ###SSL Ciphers ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA'; ###Extra Settings### ssl_prefer_server_ciphers on; ssl_session_cache shared:SSL:10m; ### Add HTTP Strict Transport Security ### add_header Strict-Transport-Security "max-age=63072000; includeSubdomains"; add_header Front-End-Https on; client_max_body_size 0; location /stunnel { proxy_pass https://192.168.1.105:8998/stunnel/; include /config/nginx/proxy.conf; } } When I restart the Let's Encrypt Docker and attempt to connect to https://fake.archedraft.server.name.org/stunnel - I revived the following message in my browser: 404 Not Found nginx/1.14.0 Any ideas on what I am screwing up?