DavidSpek

Do I understand correctly that unRAID will support iSCSI with this release or the 6.9 stable release? If not I think this is definitely a welcome feature.

Given the power management fixes in the new 450.36.06 driver (and assuming also newer ones once they are released), would it be possible to add this driver once it is available through SlackBuild? I know the usual procedure it to have one release for each unraid build unless there is a critical bug, but given the fact that many use their GPU's for Plex transcoding and power usage in P8 is ~30% of the power usage in P0 wit a P2000 I think it is debatable if this should be considered critical. Reading through the thread I linked earlier the issue with Plex and power management was actually something Nvidia needed to fix in their driver and was not caused by an issue in Plex (even though Emby and Jellyfin don't seem to have this issue), which also supports the notion that this is a bug in the driver.

Not sure if this has been requested already, but could the driver version be updated to 450.36.06? There is a bug with Plex where the GPU stays in power state P0 after transcoded streams are terminated and this is supposed to be fixed in the new Nvidia driver. https://forums.plex.tv/t/stuck-in-p-state-p0-after-transcode-finished-on-nvidia/387685/101

As others have already said downgrading the firmware from P20 to P16 fixes TRIM on my 860 EVO. However, I recently upgraded my regular H310 to an H710 mini mono card in my R720xd and I'd like to share a few things. First off, a tool has been made which will effortlessly flash H310 mini mono, H710(p) mini mono and H710(p) full sized cards (https://fohdeesha.com/docs/perc/). I followed this procedure for my H710 rev. D1 and it worked flawlessly. The issue is that this tool uses P20 firmware and replacing the P20 firmware file with a P16 firmware one stops the tool from working as it can't boot the P16 firmware from RAM. Due to the mini mono cards needing some special flashing techniques to not brick them, I wasn't sure how to attempt to downgrade the card from P20 to P16. In the end I managed to downgrade the firmware in a very simple matter. I copied the P16 firmware for my card to the location where the other firmware is stored and named it 9207-8_p16.bin. Then, I modified the line in the D1-H710 script that flashes the card to use the 9207-8_p16.bin instead of the regular P20 version. To clarify, this script will boot the card with P20 firmware from RAM, and then proceed to flash the P16 firmware to the card. All in all, it was very simple to do and I see no reason why flashing the card directly in this manner would not work either. For more info on the matter see this GitHub issue https://github.com/Fohdeesha/lab-docu/issues/6.

I created a docker version of a tool to create the labels on HDD caddies of HP and Dell Servers. If anybody has issues please let me know. https://github.com/BShurilla/homelablabelmaker https://hub.docker.com/repository/docker/davidspek/homelablabelmaker

I'm having this same issue both when trying to send the ebook to a kindle or just opening a file. I've checked the paths and changed them to be consistent (even though as mentioned the importing of the downloaded books to the library location is working fine). I've also tried new permissions on the files but nothing has been able to fix it. Without being able to open/download the books from LL or send it to a kindle this whole program is fairly useless sadly.

I honestly had no idea the backups were taking 3 hours. Could it be that I am manually starting the docker containers before the backup is complete, as I usually check around 7:30 am? Regarding the scheduling, should I turn off the auto-update schedule and let the backup app schedule the update, or schedule the auto-update at a different point in time? Also, is there a way to reduce the time it takes to make a backup? Sorry for the large amount of questions, but I am guessing this information is probably also applicable for others. Again, thank you for the help.

For the past 2 weeks or so I have also been having the problem that the CA Backup/Restore is stopping my dockers but not restarting them. However, in the morning I am just able to properly start all my dockers manually without any problem. This has been happening almost every night, but not always strangely enough. The Backup is run at 5 am and the auto update runs at 6 am. This is an example of the system log for one of the containers but it is nearly the same for all of them (except the port X (vetheXXXXXX) entered disabled state. Oct 10 05:00:01 Tower CA Backup/Restore: Stopping antennas Oct 10 05:01:01 Tower kernel: veth1ff6810: renamed from eth0 Oct 10 05:01:01 Tower kernel: docker0: port 9(vethe0d1822) entered disabled state Oct 10 05:01:02 Tower avahi-daemon[9942]: Interface vethe0d1822.IPv6 no longer relevant for mDNS. Oct 10 05:01:02 Tower avahi-daemon[9942]: Leaving mDNS multicast group on interface vethe0d1822.IPv6 with address fe80::e42f:30ff:fee0:8bb1. Oct 10 05:01:02 Tower kernel: docker0: port 9(vethe0d1822) entered disabled state Oct 10 05:01:02 Tower kernel: device vethe0d1822 left promiscuous mode Oct 10 05:01:02 Tower kernel: docker0: port 9(vethe0d1822) entered disabled state Oct 10 05:01:02 Tower avahi-daemon[9942]: Withdrawing address record for fe80::e42f:30ff:fee0:8bb1 on vethe0d1822. Oct 10 05:01:03 Tower CA Backup/Restore: docker stop -t 60 antennas After this auto update of the dockers runs without any error that I can see and this is the output from me starting the dockers manually. Oct 10 07:34:13 Tower kernel: br-a91e46b94306: port 1(vethf1af6d1) entered blocking state Oct 10 07:34:13 Tower kernel: br-a91e46b94306: port 1(vethf1af6d1) entered disabled state Oct 10 07:34:13 Tower kernel: device vethf1af6d1 entered promiscuous mode Oct 10 07:34:13 Tower kernel: IPv6: ADDRCONF(NETDEV_UP): vethf1af6d1: link is not ready Oct 10 07:34:13 Tower kernel: br-a91e46b94306: port 1(vethf1af6d1) entered blocking state Oct 10 07:34:13 Tower kernel: br-a91e46b94306: port 1(vethf1af6d1) entered forwarding state Oct 10 07:34:13 Tower kernel: br-a91e46b94306: port 1(vethf1af6d1) entered disabled state Oct 10 07:34:14 Tower kernel: eth0: renamed from veth38fb9c8 Oct 10 07:34:14 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethf1af6d1: link becomes ready Oct 10 07:34:14 Tower kernel: br-a91e46b94306: port 1(vethf1af6d1) entered blocking state Oct 10 07:34:14 Tower kernel: br-a91e46b94306: port 1(vethf1af6d1) entered forwarding state Oct 10 07:34:14 Tower kernel: br-a91e46b94306: port 2(vetha16a16d) entered blocking state Oct 10 07:34:14 Tower kernel: br-a91e46b94306: port 2(vetha16a16d) entered disabled state Oct 10 07:34:14 Tower kernel: device vetha16a16d entered promiscuous mode Oct 10 07:34:14 Tower kernel: IPv6: ADDRCONF(NETDEV_UP): vetha16a16d: link is not ready Oct 10 07:34:14 Tower kernel: br-a91e46b94306: port 2(vetha16a16d) entered blocking state Oct 10 07:34:14 Tower kernel: br-a91e46b94306: port 2(vetha16a16d) entered forwarding state Oct 10 07:34:15 Tower kernel: br-a91e46b94306: port 2(vetha16a16d) entered disabled state Oct 10 07:34:15 Tower avahi-daemon[9942]: Joining mDNS multicast group on interface vethf1af6d1.IPv6 with address fe80::245e:1aff:fec9:5b64. Oct 10 07:34:15 Tower avahi-daemon[9942]: New relevant interface vethf1af6d1.IPv6 for mDNS. Oct 10 07:34:15 Tower avahi-daemon[9942]: Registering new address record for fe80::245e:1aff:fec9:5b64 on vethf1af6d1.*. Oct 10 07:34:15 Tower kernel: eth0: renamed from veth68dd4be Oct 10 07:34:15 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vetha16a16d: link becomes ready Please let me know if other information is needed and thank you all for the help. tower-diagnostics-20191010-1637.zip

I had quite a bit of trouble getting OnlyOfficeDocumentServer to work with nextcloud and letsencrypt. So I had letsencrypt install for plex etc and got it working with nextcloud. The confusing part of getting OnlyOfficeDocumentServer to work with letsencrypt is that you need to create self-signed ssl certificates for the docker container itself, and then have letsencrypt create certificates for your public address. So a short overview of the steps I took. I left the ports of the container default as I wanted to eliminate potential problems. 1. Install the OnlyOfficeDocumentServer container. Leave everything as default (the name can contain capitals for the setup I have, network is bridge). 2. Add your subdomain to the letsencrypt container, and add the file onlyofficedocumentserver.subdomain.conf with the content below in the folder /appdata/letsencrypt/nginx/proxy-confs/. Please change the server_name to [YOUR SUBDOMAIN].*; and proxy_pass to https://[YOUR UNRAID SERVER IP]:4430/. Also, the formatting of the first, second and forth line seems to be off in this field and the extra tab/spaces should be there. server { listen 443 ssl; server_name oods.*; include /config/nginx/ssl.conf; client_max_body_size 0; location / { include /config/nginx/proxy.conf; resolver 127.0.0.11 valid=30s; set $upstream_oods onlyofficedocumentserver; proxy_pass https://192.168.178.65:4430/; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Host $server_name; proxy_set_header X-Forwarded-Proto $scheme; } } 3. Restart letsencrypt container to get a certificate for your new subdomain. 4. Check that OnlyOfficeDocumentServer is accessible via http://[YOUR UNRAID IP]:8080 (note this is HTTP and not HTTPS yet). 5. Create the certs folder and certificates for OnlyOfficeDocumentServer using the following command in an unraid terminal (I used the unraid web terminal). Note that the second openssl command will request various data to be filled in and that this certificate will be valid for 365 days. cd /mnt/user/appdata/onlyofficeds/Data mkdir certs cd certs openssl genrsa -out onlyoffice.key 2048 openssl req -new -key onlyoffice.key -out onlyoffice.csr openssl x509 -req -days 365 -in onlyoffice.csr -signkey onlyoffice.key -out onlyoffice.crt 5. Check that OnlyOfficeDocumentServer is now accessible via https://[YOUR UNRAID IP]:4430. You will get an warning that the server has a self signed certificate. At this point the http address of OnlyOfficeDocumentServer was not accessible anymore for me. 6. Check that OnlyOfficeDocumentServer is now accessible through letsencrypt and your subdomain.domain.com (for me oods.xxxxxxx.com). When looking at the certificate of my domain, it seems all certificates are verified by letsencrypt and I saw no remnant of the self-signed certificates (with plex I do see some warnings about certificate redirects or something when looking at the developer tools of chrome, but this causes no issue and clicking the lock icon shows it to be fine). 7. Go to your nextcloud, install the onlyoffice plugin. 8. Go to settings, then OnlyOffice and fill in https://[subdomain].[domain].com and everything should now all be working. I hope this helps some others that have been struggling with this and find the need for self-signed and letsencrypt certificates confusing. When I tried to use the letsencrypt certificates in the /Data/certs folder I got an error in the OnlyOfficeDocumentServer container log that nginx failed to start. I did, however, only create the onlyoffice.crt and onlyoffice.key from my letsencrypt fullchain.pem and privkey.pem and did not create the onlyoffice.csr. Also, if there is a way to get the letsencrypt certificates working I would be very interested to know how to do this. For a next step I would like to implement the secret that can be filled in within nextcloud, however, I have not fully looked into doing this with these docker containers yet.