Jump to content


Community Developer
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by ljm42

  1. Another vote for PhotoSync. Set it and forget it, both Android and iOS
  2. CAs are not allowed to generate a certificate for because that would work on many computers, it does not uniquely identity one machine. They can however generate certs for any Fully Qualified Domain Name (i.e. xyz.unraid.net), and there is no restriction on what IP address the DNS for that FQDN actually points to. Your browser is able to connect to because it is an insecure connection, no SSL cert required. Unraid responds and redirects to the proper FQDN for the https connection. Your browser refuses to connect to (regardless of port) because the browser is asking for a secure connection and Unraid doesn't have a certificate that matches "" (per the comment above). Since your browser refuses to make an https connection without a valid cert, it never finds out that Unraid just wants to redirect it to the proper FQDN
  3. Here is a tip from: Create a file called startup.nsh in the root of the flash drive which contains the single line below: \EFI\boot\bootx64.efi
  4. Open the file in a good editor (such as Notepad++ , not Notepad) and save it with Unix line endings (LF) not Windows line endings (CR LF)
  5. I typically shut my system down carefully, by first stopping the VMs, then stopping the array, then powering down. Today I went straight for "stop array" and ended up with an unclean shutdown. Some research brought me to this helpful post by @dlandon: Basically, these settings must be in sync to get your system to shutdown gracefully: "Settings->VM Manager->VM Shutdown time-out": must be long enough to allow your VMs to shutdown "Settings->Disk Settings->Shutdown time-out": must be long enough for the array to stop *after* VMs have shutdown. So 60 to 120 seconds longer than the VM timeout. "Settings->UPS Settings->Time on battery": must be short enough that the system will have enough power to stay on for the entire "disk settings shutdown time-out" Additionally, "Settings->UPS Settings->Turn off UPS after shutdown" seems extremely risky and should only be used if you know your UPS will stay on longer than the "disk settings shutdown time-out". I don't see any options to configure this. Currently the UI provides no help in tying these settings together. So the request is: Adjust the UI so that it won't allow you to set the disk settings shutdown timeout less than the VM shutdown timeout (plus perhaps a minimum additional delay?) Adjust the UI on the UPS Settings page to make it clear that you need to trigger the shutdown early enough to allow the system to run for at least as long as the "disk settings shutdown time-out" Add a warning telling users they probably don't want to enable the "Turn off UPS after shutdown" option It may be worth adding a new "Settings->Powerdown" page that contains all of the relevant settings in one place A secondary request for @Squid: updating the UI to help people put in reasonable values is great, but will only help if you are looking at those screens. Perhaps FCP can alert the user if these settings are out of sync?
  6. Just FYI - A few versions back Unraid added a robots.txt file, which should keep legitimate search engines from indexing a server that is placed on the Internet.
  7. Please see this guide: AFAIK it details the best way to run Unraid as a guest on an Unraid host.
  8. Very cool @Squid! FCP is awesome for this type of proactive notification No false positives here.
  9. @Squid is this something Fix Common Problems could detect?
  10. hmm... git doesn't seem to be installed in 6.7.0? root@Tower:~# git -bash: git: command not found root@Tower:~# whereis git git: root@Tower:/var/log/packages# ls git* /bin/ls: cannot access 'git*': No such file or directory
  11. This thread was obsoleted three years ago, but I went ahead and updated it to acknowledge that issues with transcoding to RAM may have changed since then. If you'd like to discuss that topic I'd suggest visiting the Plex: Guide to Moving Transcoding to RAM thread.
  12. If it works for you, great! But if you start having issues with Plex, this is the first thing I would change.
  13. Looking at top.txt file in your diags, Plex was indeed using 100% of your CPU at the time you generated your diagnostics: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5958 nobody 20 0 1314160 75948 36220 S 100.0 0.9 13:52.16 Plex Medi+ see this I didn't recognize that, but a Google search for "unraid ACPI BIOS Error" says it is harmless, although you might try checking for a bios update: https://forums.unraid.net/topic/75337-acpi-bios-errors-in-syslog/
  14. It is a valid question, the Linux drivers for those cards may not be included in Unraid. If nobody can give you a direct yes or no, I would do a Google search for "unraid x470" and "unraid 10gbe" to see what you can find
  15. I have had mixed results with https://ipaddress . At a minimum you will need to bypass the browser warnings telling you that the certificate doesn't match the url. http://ipaddress will automatically redirect to https://hash.unraid.net . If your computer hasn't cached that address already and your Internet is down, it won't be able to do a DNS lookup, which causes the issue you are seeing. One solution is to add an entry to your local hosts file that points hash.unraid.net to the correct IP address. The downside is that this overrides DNS, so you need to remember to update the hosts file if the IP address ever changes. Another solution is to disable SSL by editing the /boot/config/ident.cfg file and changing USE_SSL to "no", then typing "powerdown -r" from the console to reboot. When it comes back up you will be able to use http://ipaddress to access the gui.
  16. I guess this is a good time to mention that you need to be careful when editing this file Also, be sure to use a good text editor that understands Linux line endings (such as Notepad++), definitely not the standard Windows Notepad.
  17. That starts the webgui. It is in your go script already, I was just showing that you want to copy the file before that line so the array will be able to auto-start.
  18. Copy the keyfile to /root . Easiest way is to add the copy command to /boot/config/go, before you start emhttp #!/bin/bash # let encrypted array auto-start (obviously, not secure) cp /boot/config/custom/keyfile /root # Start the Management Utility /usr/local/sbin/emhttp &
  19. Any response would just be speculation at this point. If you upload your diagnostics someone might have some ideas (Tools -> Diagnostics, then attach entire zip file to your next post)
  20. Sorry... I was looking in rc.nginx for other places to use this, and I realized the function name should be more like wait_nginx_down instead of wait_nginx_status It can easily replace the "sleep 3" in nginx_term and nginx_stop. But what about nginx_reload, is that actually waiting for nginx to be up instead of down?
  21. Looks like this is the right syntax for the if statement, the double brackets didn't work: wait_nginx_status() { for i in {1..10} ;do if ! nginx_status ;then break ;fi sleep 1 done }
  22. Hey @limetech I hit this today in 6.7.0-rc5. But when I ran: /etc/rc.d/rc.nginx restart nginx shutdown and did not start backup: Checking configuration for correct syntax and then trying to open files referenced in configuration... nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful Shutdown Nginx gracefully... Nginx is already running It looks like it tried to start back up before it finished shutting down, so it exited. I had to manually start it to get it running again: /etc/rc.d/rc.nginx start I was looking at rc.nginx, what do you think of creating a wait_nginx_status function: wait_nginx_status() { while nginx_status; do echo "Waiting..." sleep 1 done } And then replacing all of the "sleep 3"s with that: nginx_stop() { if nginx_running ; then echo "Shutdown Nginx gracefully..." killall -q ttyd &>/dev/null kill -QUIT $(cat $PID) # sleep 3 wait_nginx_status fi } Doesn't solve the original problem but it should help make the rc.nginx more bulletproof.
  23. I keep thinking about this. I can't think of a reason why anybody would want a bunch of log files at the root of any share, unless they create the share specifically for this purpose. Would it make sense to automatically create and use a "logs" directory under whatever share the user chooses? That feels more organized out of the box.
  24. I put together a little script that copies your custom *.conf files from the flash drive to /etc/rsyslog.d and then restarts rsyslogd. You can run it interactively to test new filters and add it to your go script to install them after rebooting. Thought I'd share if anyone is interested: https://gist.github.com/ljm42/f6d7d8f22d2965909f69c03df53529f6