Leaderboard

I had to edit this Post because I got it running. I am trying to make it more stable and will publish it to the conmunity Apps very soon. You will find the support thread here: Cheers

Application Name: ddclient Application Site: https://github.com/ddclient/ddclient Docker Hub: https://hub.docker.com/r/linuxserver/ddclient/ Github: https://github.com/linuxserver/docker-ddclient Please post any questions/issues relating to this docker you have in this thread. If you are not using Unraid (and you should be!) then please do not post here, rather use the linuxserver.io forum for support.

tldr: If you are running Unraid OS 6 version 6.8.1 or later, the following does not apply (mitigations are in place). If you are running any earlier Unraid OS 6 release, i.e., 6.8.0 and earlier, please read on. On Jan 5, 2020 we were informed by a representative from sysdream.com of security vulnerabilities they discovered in Unraid OS. Their report is attached to this post. At the time, version 6.8.0 was the stable release. The most serious issue concerns version 6.8.0. Here they discovered a way to bypass our forms-based authentication and look at the contents of various webGUI pages (that is, without having to log in first). Then using another exploit, they were further able to demonstrate the ability to inject "arbitrary code execution". Someone clever enough could use this latter exploit to execute arbitrary code on a server. (That person would have to have access to the same LAN as the server, or know the IP address:port of the server if accessible via the Internet.) Even in versions prior to 6.8.0, the "arbitrary code execution" vulnerability exists if an attacker can get you to visit a webpage using a browser that is already logged into an Unraid server (and they know or can guess the host name of the server). In this case, clicking the link could cause injection of code to the server. This is similar to the CSRF vulnerability we fixed a few years ago. In summary, sysdream.com recognizes 3 vulnerabilities: That it's possible to bypass username/password authentication and access pages directly in v6.8.0. That once authentication is bypassed, it's possible to inject and have server execute arbitrary code. That even if bug #1 is fixed, #2 is still possible if attacker can get you to click a link using browser already authenticated to your Unraid server (6.8.0 and all earlier versions of Unraid 6). Mitigations are as follows: First, if you are running version 6.8.0, either upgrade to latest stable release, or downgrade to an earlier release and install the sysdream mitigation plugin. We are not going to provide a mitigation plugin for 6.8.0. If you are running any 6.6 or 6.7 Unraid release, the best course of action is to upgrade to the latest stable release; otherwise, please install this mitigation plugin: https://raw.githubusercontent.com/limetech/sysdream/master/sysdream.plg This plugin will make a small patch to the webGUI template.php file in order to prevent arbitrary code execution. This plugin will work with all 6.6.x and 6.7.x releases and should also be available via Community Apps within a couple hours. We are not going to provide a mitigation for Unraid releases 6.5.x and earlier. If you are running an earlier release and cannot upgrade for some reason, please send us an email: [email protected]. I want to thank sysdream.com for bringing this to our attention, @eschultz for initial testing and fixes, and @bonienl for creation of the sysdream mitigation plugin. I also want to remind everyone: please set a strong root password, and carefully consider the implications and security measures necessary if your server is accessible via the Internet. Finally, try and keep your server up-to-date. VULNERABILITY_DISCLOSURE.pdf

While the current system is great for the average home network as a media server storing non-critical and non-confidential information on a private network, with a few changes, it could be ready for so much more... Where I'm coming from: I'm new to unraid, and I am a long time Linux-user with widows as a side OS I avoid as much as possible. Currently I've been setting up a VFIO system, and because I won't just be using it to store media but to actually be my daily driver, I have certain security concerns with the current default configurations. The following is a list of changes I've compiled, largely from http://kmwoley.com/blog/securing-a-new-unraid-installation/ and somewhat ordered by importance: - SMB 1 disabled by default - FTP and Tellnet disabled by default - HTTPS enabled with a self-signed cert out of the gate (love the cert authority setup though!) - make it more clear how to encrypt new drives (can't choose to encrypt when adding the device, has to be changed in the default filesystem setting) - new shares not exported by default, and when exportrd, Private by default - Don't export the USB boot media!!! (At least not by default and add an are you sure if you try to enable it) - firewall such as UFW installed and enabled by default with only TCP port 80 and 443 set to LIMIT and whatever SMB uses opened. GUFW could be pulled from for the GUI. And providing quick check boxes for common ports would make it easy, possiblity auto enabling when you enable a core service. - Docker Isolation through Linux namespaces / subuids - allow tagging more shares for direct Linux VM mounting to prevent the need to pass through /mnt/user - better multiple-user support, it's a server, right? So people other than root should be able to ssh in and access the UI; ideally root login would be disabled with use of a wheel group instead - don't use 777 permissions by default, ideally users + groups, but at a minimum there is no reason for most things to be read, write, and execute by default! - support for openvpn - support for multiple different encryption keys And add other lurking issues to this. Even if you're not exposing a system to the public internet, a lot of these things can still cause problems if the system is up 24/7. There is no such thing as a "friendly environment" outside air-gapped systems, and my daily driver will definitely not be air gapped. Anyway, if you've made it this far and feel like this is a list of complaints, I'm sorry. I do like unraid and I already feel excited for where it's going.

No Referrals An extremely simple plugin that will block the referral header from being sent if you click on any link to an outside website from within unRaid's GUI. ie: the 3rd Party website will not know your server's URL address. Minimum version required to run is 6.7.0, and that's only because for something that's this simple, it's way too much work for me to support the different icon scheme on the older unRaid versions.

From the terminal if you can get at it, diagnostics I suspect though that this has nothing at all to do with preclear (unless you actually ran it and tried to preclear your flash drive), but that the flash drive dropped offline for some reason (USB2 ports are always recommended as they are far more reliable than USB3)

Did you go to your google account and created a new App password? If you you 2-step verification then this is the way to get bitwarden to log in to your gmail account. https://myaccount.google.com/apppasswords

Have you tried rebooting?

I'd like to know the answer to this also....

Added. Don't know why it wasn't copied to the 6.7 or 6.8 repo Edit: actually it's already included in unraid. That's why it was removed from NerdPack

You can always run multiple instances of the same docker. Just use a different names + different appdata folder I would prefer docker over VM at the first instance. VM requires KVM/qemu overhead which makes it less efficient so I would only use VM for things that I can't do with docker.

I was having the same issue on a HGST 3TB SAS drive, getting stuck at 90% and restarting. It has finished preclear successfully after the update! Thanks!

The docker with cuda support is building now. You need to install the Nvidia plugin and set up the docker for cuda support. Read the first post for instructions on how to set up cuda.

As you say, somewhat an overkill build. CPU's, if you want gaming then high frequency will be better. My real question is memory, performance will be significantly crippled with just 2 Dimms. The CPU's share memory badly as latency would be really high across a shared bus, Ideally you want each CPU to have it's own memory and 16GB shared between 12 to 24 cores is very stingy. Socket 2011 V3 is Quad channel so for best performance you need 4 Dimms per CPU, for tolerable performace you could live with 2, but 1 DIMM per CPU seems like a real performance killer. I recently bought 4 x 16GB RDIMM 2133 new, brown box in UK for ~ EUR50 per stick so your ram is also expensive. Most of the Xeons are capped at 2133 anyhow so 2400Mhz is mostly moot. Perhaps a single E5-2690 12C 24T 2.6Ghz / 3.5Ghz with 4 x 16GB would be a comprimise. Pass mark 19k hence why I don't see much point in dual CPU in consumer space. In a server farm with optimisation dual CPU makes more sense. For extra SATA use a cheap reflashed LSI SAS card, some random SATA card will only be trouble. What are you pluging you Samsung M.2 into? no slots on that board so will need a PCI-E adapter. Super fast and high IOPS makes little difference in the consumer space, mostly cache is just that, cache + log files etc. I'm using a standard mirrored pair of SATA SSD's and nothing I run including a few game servers causes them any stress. Drives - if you want to go big, I'd be buying 14TB+ Drives for parity and any new drives, add in the 8TB you have but if going big, why 8TB? Just have to look out for the Amazon etc deals and shuck the drives.

Winner winner chicken dinner root@nas:~# fstrim -v /mnt/disks/Samsung_SSD_860_EVO_2TB_S597NJ0MC06295J /mnt/disks/Samsung_SSD_860_EVO_2TB_S597NJ0MC06295J: 1.8 TiB (1999323762688 bytes) trimmed So I would say avoid the 4TB for now. Odd though since the only difference between the 2TB model and the 4TB model is the amount of LPDDR4 DRAM. I wonder if it has anything to do with the block size (like 512b vs 4k on > 2TB HDDs). I sort of want to try another 4TB drive. The reason why I went with the 860 EVO was because of the endurance rating. If you guys know another 4TB drive that would TRIM fine and has decent endurance rating, please let me know. Thanks!

Please make 2FA an optional feature. My server is not exposed to the Internet so there's really no need for extra security. It would be a massive pain in the backside having to grab my phone just to check if a docker has crashed.

Something else I wanted to add, as long as we're talking about security measures in the pipe: we are looking at integrating various 2-Factor solutions directly in Unraid OS, such as google authenticator.

This is basic docker stuff. I suggest you read the docker faq to learn about the basics of docker. /config inside the container is the appdata folder on the host side (unraid). So /config/cache inside the container is /whatever_you_mapped_as_appdatafolder/cache on Unraid. Probably /mnt/cache/appdata/jellyfin/

I haven't "danced" around anything, sorry if it appears like that. How does this apply in an Unraid server environment? Yes this is something we're looking at. why? why? There is only one user: root You can set file permissions however you want using standard linux command line tools. Again, what are you trying to accomplish? We do have plans to introduce the idea of multiple admin users with various roles they can take on within the Management Utility. For example, maybe you create a user named "Larry" who only has access to the Shares page with ability to browse shares only they have access to. However this functionality is not high on the list of features we want/need to implement. Earlier you were confused by my term "appliance". What this means is the server has a single user that can manage the box. If you don't have the root user password, all you can do is access shares on the network that you have permission for, and access Docker webUI's - but most of these have their own login mechanism. Things like the flash share exported by default, new shares public by default, telnet enabled by default, SMBv1 enabled by default, etc. are all simplifications to reduce frustration by new users. Nothing more frustrating that creating a share and then getting "You do not have permission..." when trying to browse your new share. We are trying to reduce the swearing and kicking of dogs by new users just trying to use the server. Eventually everyone needs to be more security conscious - and in that spirit we are working on "wizards" that will guide a user to setting up the correct settings for their needs. I hope this starts to answer some questions and sorry if I came across flippant to your concerns, but trust me, security is a foremost concern and to have someone imply otherwise ticks me off to be honest.

I have two of those (the Back-UPS Pro 1500VA BR1500GI version from the same range) and they work great out of the box with unraid.

These instructions should be stickied! THANK YOU!

I spent the last 6 hours searching the forum reading advice and testing things to try to solve the problem with some torrents not downloading because of port 6881 and the red ball at the bottom because of this port. It's a super easy fix, but was not explained in any one place and I thought I might save someone else a ton of time in the future. So here goes my quick tutorial. First, you need to open a port though your VPN (NOT YOUR ROUTER). AirVPN which is well supported has a simple page to use, pick a number between 10000 and 50000 and use it for both the Port number and local port number. This is a great first step, it will keep you from picking a port already in use. Second, make sure the docker is stopped and open the rtorrent.rc file it should be located at appdata\binhex-rtorrentvpn\rtorrent\config. On each of the following lines you will need to delete the # at the beginning of the line On line 77 change the range of network.port_range.set = make the starting and ending number your port number from the first step. On line 115 set dht.mode.set = on On line 119 dht.port.set = your port number Save the file and start the docker. I hope this helps someone in the future.

NVM, I figured it out For reference, my file looks like this: default menu.c32 menu title Lime Technology, Inc. prompt 0 timeout 50 label unRAID OS menu default kernel /bzimage append initrd=/bzroot i915.alpha_support=1 label unRAID OS GUI Mode kernel /bzimage append initrd=/bzroot,/bzroot-gui label unRAID OS Safe Mode (no plugins, no GUI) kernel /bzimage append initrd=/bzroot unraidsafemode label unRAID OS GUI Safe Mode (no plugins) kernel /bzimage append initrd=/bzroot,/bzroot-gui unraidsafemode label Memtest86+ kernel /memtest

Interestingly, with all prior versions of unRAID, booting in legacy mode with this board (ASRock C236 WSI) was no problem. Something changed in unRAID 6.5.0 that no longer allows legacy boot. Limetech is not sure what changed as they did nothing that, to their knowledge, would impact that. However, since a roll-back to 6.4.1 once again boots the board in legacy mode, something must have changed in the Linux kernel with the current release. Perhaps other boards will be similarly affected in the future. The fix for this board involves making sure UEFI boot is the ONLY boot option in the BIOS. If other boot options exist, it fails to boot even if UEFI is the first priority.

How do I replace/upgrade my single cache device? (unRAID v6.2 and above only) This procedure assumes that there are at least some dockers and/or VMs related files on the cache disk, some of these steps are unnecessary if there aren't. Stop all running Dockers/VMs Settings -> VM Manager: disable VMs and click apply Settings -> Docker: disable Docker and click apply For v6.11.5 or older: Click on Shares and change to "Yes" all cache shares with "Use cache disk:" set to "Only" or "Prefer" For v6.12.0 or newer: Click on all shares that are using the pool you want to empty and change them to have the pool as primary storage, array as secondary storage and mover action set to move from pool to array Check that there's enough free space on the array and invoke the mover by clicking "Move Now" on the Main page When the mover finishes check that your cache is empty (any files on the cache root will not be moved as they are not part of any share) Stop array, replace cache device, assign it, start array and format new cache device (if needed), check that it's using the filesystem you want For v6.11.5 or older: Click on Shares and change to "Prefer" all shares that you want moved back to cache For v6.12.0 or newer: Click on Shares and change the mover action to move from array to pool for all shares that you want moved back to cache On the Main page click "Move Now" When the mover finishes re-enable Docker and VMs