Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 11/29/19 in all areas

  1. 94 points
    Those following the 6.9-beta releases have been witness to an unfolding schism, entirely of my own making, between myself and certain key Community Developers. To wit: in the last release, I built in some functionality that supplants a feature provided by, and long supported with a great deal of effort by @CHBMB with assistance from @bass_rock and probably others. Not only did I release this functionality without acknowledging those developers previous contributions, I didn't even give them notification such functionality was forthcoming. To top it off, I worked with another talented developer who assisted with integration of this feature into Unraid OS, but who was not involved in the original functionality spearheaded by @CHBMB. Right, this was pretty egregious and unthinking of me to do this and for that I deeply apologize for the offense. The developers involved may or may not accept my apology, but in either case, I hope they believe me when I say this offense was unintentional on my part. I was excited to finally get a feature built into the core product with what I thought was a fairly eloquent solution. A classic case of leaping before looking. I have always said that the true utility and value of Unraid OS lies with our great Community. We have tried very hard over the years to keep this a friendly and helpful place where users of all technical ability can get help and add value to the product. There are many other places on the Internet where people can argue and fight and get belittled, we've always wanted our Community to be different. To the extent that I myself have betrayed this basic tenant of the Community, again, I apologize and commit to making every effort to ensure our Developers are kept in the loop regarding the future technical direction of Unraid OS. sincerely, Tom Mortensen, aka @limetech
  2. 30 points
    Welcome (again) to 6.9 release development! This release marks hopefully the last beta before moving to -rc phase. The reason we still mark beta is because we'd like to get wider testing of new multiple-pool feature, as well as perhaps sneak in a couple more refinements. With that in mind, the obligatory disclaimer: Important: Beta code is not fully tested and not feature-complete. We recommend running on test servers only! That said, here's what's new in this release... Multiple Pools This features permits you to define up to 35 named pools, of up to 30 storage devices/pool. The current "cache pool" is now simply a pool named "cache". Pools are created and managed via the Main page. Note: When you upgrade a server which has a cache pool defined, a backup of config/disk.cfg will be saved to config/disk.cfg.bak, and then cache device assignment settings are moved out of disk.cfg and into a new file, config/pools/cache.cfg. If later you revert back to a pre-6.9 Unraid OS release you will lose your cache device assignments and you will have to manually re-assign devices to cache. As long as you reassign the correct devices, data should remain intact. When you create a user share, or edit an existing user share, you can specify which pool should be associated with that share. The assigned pool functions identically to current cache pool operation. Something to be aware of: when a directory listing is obtained for a share, the unRAID array disk volumes and all pools which contain that share are merged in this order: pool assigned to share disk1 : disk28 all the other pools in strverscmp() order. As with the current "cache pool", a single-device pool may be formatted with either xfs, btrfs, or reiserfs. A multiple-device pool may only be formatted with btrfs. A future release will include support for multiple "unRAID array" pools. We are also considering zfs support. Something else to be aware of: Let's say you have a 2-device btrfs pool. This will be what btrfs calls "raid1" and what most people would understand to be "mirrored disks". Well this is mostly true in that the same data exists on both disks but not necessarily at the block-level. Now let's say you create another pool, and what you do is unassign one of the devices from the existing 2-device btrfs pool and assign it to this pool. Now you have x2 1-device btrfs pools. Upon array Start user might understandably assume there are now x2 pools with exactly the same data. However this is not the case. Instead, when Unraid OS sees that a btrfs device has been removed from an existing multi-device pool, upon array Start it will do a 'wipefs' on that device so that upon mount it will not be included in the old pool. This of course effectively deletes all the data on the moved device. Language Translation A huge amount of work and effort has been implemented by @bonienl to provide multiple-language support in the Unraid OS Management Utility, aka, webGUI. There are several language packs now available, and several more in the works. Thanks to @Squid, language packs are installed via the Community Applications plugin - look for a new category entitled Language. Note: Community Applications HAS to be up to date to install languages. Versions of CA prior to 2020.05.12 will not even load on this release. As of this writing, the current version of CA is 2020.06.13a. See also here. Each language pack exists in public Unraid organization github repos. Interested users are encouraged to clone and issue Pull Requests to correct translations errors. Language translations and PR merging is managed by @SpencerJ. Linux Kernel Upgraded to 5.7. Unfortunately, none of the out-of-tree drivers compile with this kernel. In particular, these drivers are omitted: Highpoint RocketRaid r750 Highpoint RocketRaid rr3740a Tehuti Networks tn40xx If you require one of these drivers, please create a Bug Report and we'll spend some time looking for alternatives. Better yet, pester the manufacturer of the controller and get them to update their drivers. Base Packages All updated to latest versions. In addition, Linux PAM has been integrated. This will permit us to install 2-factor authentication packages in a future release. Docker Updated to version 19.03.11 Also now possible to select different icons for multiple containers of the same type. This change necessitates a re-download of the icons for all your installed docker applications. A delay when initially loading either the dashboard or the docker tab while this happens is to be expected prior to the containers showing up. Virtualization libvirt updated to version 6.4.0 qemu updated to version 5.0.0 In addition, integrated changes to System Devices page by user @Skitals with modifications by user @ljm42. You can now select PCI devices to isolate from Linux upon boot simply by checking some boxes. This makes it easier to reserve those devices for assignment to VM's. Note: If you had the VFIO-PCI Config plugin installed, you should remove it as that functionality is now built-in to Unraid OS 6.9. Refer also @ljm42's excellent guide. In a future release we will include the NVIDIA and AMD GPU drivers natively into Unraid OS. The primary use case is to facilitate accelerated transcoding in docker containers. For this we require Linux to detect and auto-install the appropriate driver. However, in order to reliably pass through an NVIDIA or AMD GPU to a VM, it's necessary to prevent Linux from auto-installing a GPU driver for those devices upon boot, which can be easily done now through System Devices page. Users passing GPU's to VM's are encouraged to set this up now. "unexpected GSO errors" If your system log is being flooded with errors such as: Jun 20 09:09:21 Tower kernel: tun: unexpected GSO type: 0x0, gso_size 31, hdr_len 66 You need to edit each VM and change the model type for the Ethernet bridge from "virtio" to "virtio-net". In most cases this can be accomplished simply by clicking Update in "Form View" on the VM Edit page. For other network configs it may be necessary to directly edit the xml. For example: <interface type='bridge'> <mac address='xx:xx:xx:xx:xx:xx'/> <source bridge='br0'/> <model type='virtio-net'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> Other AFP support has been removed. Numerous other Unraid OS and webGUI bug fixes and improvements. Version 6.9.0-beta22 2020-06-16 Caution! This is beta sofware, consider using on test servers only. Base distro: aaa_base: version 14.2 aaa_elflibs: version 15.0 build 23 acl: version 2.2.53 acpid: version 2.0.32 apcupsd: version 3.14.14 at: version 3.2.1 attr: version 2.4.48 avahi: version 0.8 bash: version 5.0.017 beep: version 1.3 bin: version 11.1 bluez-firmware: version 1.2 bridge-utils: version 1.6 brotli: version 1.0.7 btrfs-progs: version 5.6.1 bzip2: version 1.0.8 ca-certificates: version 20191130 build 1 celt051: version 0.5.1.3 cifs-utils: version 6.10 coreutils: version 8.32 cpio: version 2.13 cpufrequtils: version 008 cryptsetup: version 2.3.3 curl: version 7.70.0 cyrus-sasl: version 2.1.27 db48: version 4.8.30 dbus: version 1.12.18 dcron: version 4.5 devs: version 2.3.1 build 25 dhcpcd: version 8.1.9 diffutils: version 3.7 dmidecode: version 3.2 dnsmasq: version 2.81 docker: version 19.03.11 dosfstools: version 4.1 e2fsprogs: version 1.45.6 ebtables: version 2.0.11 eject: version 2.1.5 elvis: version 2.2_0 etc: version 15.0 ethtool: version 5.7 eudev: version 3.2.5 file: version 5.38 findutils: version 4.7.0 flex: version 2.6.4 floppy: version 5.5 fontconfig: version 2.13.92 freetype: version 2.10.2 fuse3: version 3.9.1 gawk: version 4.2.1 gd: version 2.2.5 gdbm: version 1.18.1 genpower: version 1.0.5 getty-ps: version 2.1.0b git: version 2.27.0 glib2: version 2.64.3 glibc-solibs: version 2.30 glibc-zoneinfo: version 2020a build 1 glibc: version 2.30 gmp: version 6.2.0 gnutls: version 3.6.14 gptfdisk: version 1.0.5 grep: version 3.4 gtk+3: version 3.24.20 gzip: version 1.10 harfbuzz: version 2.6.7 haveged: version 1.9.8 hdparm: version 9.58 hostname: version 3.23 htop: version 2.2.0 icu4c: version 67.1 inetd: version 1.79s infozip: version 6.0 inotify-tools: version 3.20.2.2 intel-microcode: version 20200609 iproute2: version 5.7.0 iptables: version 1.8.5 iputils: version 20190709 irqbalance: version 1.6.0 jansson: version 2.13.1 jemalloc: version 4.5.0 jq: version 1.6 keyutils: version 1.6.1 kmod: version 27 lbzip2: version 2.5 lcms2: version 2.10 less: version 551 libaio: version 0.3.112 libarchive: version 3.4.3 libcap-ng: version 0.7.10 libcgroup: version 0.41 libdaemon: version 0.14 libdrm: version 2.4.102 libedit: version 20191231_3.1 libestr: version 0.1.11 libevent: version 2.1.11 libfastjson: version 0.99.8 libffi: version 3.3 libgcrypt: version 1.8.5 libgpg-error: version 1.38 libgudev: version 233 libidn: version 1.35 libjpeg-turbo: version 2.0.4 liblogging: version 1.0.6 libmnl: version 1.0.4 libnetfilter_conntrack: version 1.0.8 libnfnetlink: version 1.0.1 libnftnl: version 1.1.7 libnl3: version 3.5.0 libpcap: version 1.9.1 libpciaccess: version 0.16 libpng: version 1.6.37 libpsl: version 0.21.0 librsvg: version 2.48.7 libseccomp: version 2.4.3 libssh2: version 1.9.0 libssh: version 0.9.4 libtasn1: version 4.16.0 libtirpc: version 1.2.6 libunistring: version 0.9.10 libusb-compat: version 0.1.5 libusb: version 1.0.23 libuv: version 1.34.0 libvirt-php: version 0.5.5 libvirt: version 6.4.0 libwebp: version 1.1.0 libwebsockets: version 3.2.2 libx86: version 1.1 libxml2: version 2.9.10 libxslt: version 1.1.34 libzip: version 1.7.0 lm_sensors: version 3.6.0 logrotate: version 3.16.0 lshw: version B.02.17 lsof: version 4.93.2 lsscsi: version 0.31 lvm2: version 2.03.09 lz4: version 1.9.1 lzip: version 1.21 lzo: version 2.10 mc: version 4.8.24 miniupnpc: version 2.1 mpfr: version 4.0.2 nano: version 4.9.3 ncompress: version 4.2.4.6 ncurses: version 6.2 net-tools: version 20181103_0eebece nettle: version 3.6 network-scripts: version 15.0 build 9 nfs-utils: version 2.1.1 nghttp2: version 1.41.0 nginx: version 1.16.1 nodejs: version 13.12.0 nss-mdns: version 0.14.1 ntfs-3g: version 2017.3.23 ntp: version 4.2.8p14 numactl: version 2.0.11 oniguruma: version 6.9.1 openldap-client: version 2.4.49 openssh: version 8.3p1 openssl-solibs: version 1.1.1g openssl: version 1.1.1g p11-kit: version 0.23.20 patch: version 2.7.6 pciutils: version 3.7.0 pcre2: version 10.35 pcre: version 8.44 php: version 7.4.7 (CVE-2019-11048) pixman: version 0.40.0 pkgtools: version 15.0 build 33 pm-utils: version 1.4.1 procps-ng: version 3.3.16 pv: version 1.6.6 qemu: version 5.0.0 qrencode: version 4.0.2 reiserfsprogs: version 3.6.27 rpcbind: version 1.2.5 rsync: version 3.1.3 rsyslog: version 8.2002.0 samba: version 4.12.3 (CVE-2020-10700, CVE-2020-10704) sdparm: version 1.11 sed: version 4.8 sg3_utils: version 1.45 shadow: version 4.8.1 shared-mime-info: version 2.0 smartmontools: version 7.1 spice: version 0.14.1 sqlite: version 3.32.2 ssmtp: version 2.64 sudo: version 1.9.0 sysfsutils: version 2.1.0 sysvinit-scripts: version 2.1 build 31 sysvinit: version 2.96 talloc: version 2.3.1 tar: version 1.32 tcp_wrappers: version 7.6 tdb: version 1.4.3 telnet: version 0.17 tevent: version 0.10.2 traceroute: version 2.1.0 tree: version 1.8.0 ttyd: version 20200606 usbredir: version 0.7.1 usbutils: version 012 utempter: version 1.2.0 util-linux: version 2.35.2 vbetool: version 1.2.2 vsftpd: version 3.0.3 wget: version 1.20.3 which: version 2.21 wireguard-tools: version 1.0.20200513 wsdd: version 20180618 xfsprogs: version 5.6.0 xkeyboard-config: version 2.30 xorg-server: version 1.20.8 xterm: version 356 xz: version 5.2.5 yajl: version 2.1.0 zlib: version 1.2.11 zstd: version 1.4.5 Linux kernel: version 5.7.2 CONFIG_WIREGUARD: WireGuard secure network tunnel CONFIG_IP_SET: IP set support CONFIG_SENSORS_DRIVETEMP: Hard disk drives with temperature sensors enabled additional hwmon native drivers enabled additional hyperv drivers firmware added: BCM20702A1-0b05-180a.hcd out-of-tree driver status: igb: using in-tree version ixgbe: using in-tree version r8125: using in-tree version r750: (removed) rr3740a: (removed) tn40xx: (removed) Management: AFP support removed Multiple pool support added Multi-language support added avoid sending spinup/spindown to non-rotational devices get rid of 'system' plugin support (never used) integrate PAM integrate ljm42 vfio-pci script changes webgui: turn off username autocomplete in login form webgui: Added new display setting: show normalized or raw device identifiers webgui: Add 'Portuguese (pt)' key map option for libvirt webgui: Added "safe mode" one-shot safemode reboot option webgui: Tabbed case select window webgui: Updated case icons webgui: Show message when too many files for browsing webgui: Main page: hide Move button when user shares are not enabled webgui: VMs: change default network model to virtio-net webgui: Allow duplicate containers different icons webgui: Allow markdown within container descriptions webgui: Fix Banner Warnings Not Dismissing without reload of page webgui: Network: allow metric value of zero to set no default gateway webgui: Network: fix privacy extensions not set webgui: Network settings: show first DNSv6 server webgui: SysDevs overhaul with vfio-pci.cfg binding webgui: Icon buttons re-arrangement webgui: Add update dialog to docker context menu webgui: Update Feedback.php webgui: Use update image dialog for update entry in docker context menu webgui: Task Plugins: Providing Ability to define Display_Name
  3. 28 points
    Unraid Kernel Helper/Builder With this container you can build your own customized Unraid Kernel. Prebuilt images for direct download are on the bottom of this post. By default it will create the Kernel/Firmware/Modules/Rootfilesystem with nVidia & DVB drivers (currently DigitalDevices, LibreElec, XBOX One USB Adapter and TBS OpenSource drivers selectable) optionally you can also enable ZFS, iSCSI Target, Intel iGPU and Mellanox Firmware Tools (Mellanox only for 6.9.0 and up) support. nVidia Driver installation: If you build the images with the nVidia drivers please make sure that no other process is using the graphics card otherwise the installation will fail and no nVidia drivers will be installed. ZFS installation: Make sure that you uninstall every Plugin that enables ZFS for you otherwise it is possible that the built images are not working. You also can set the ZFS version from 'latest' to 'master' to build from the latest branch from Github if you are using the 6.9.0 repo of the container. iSCSI Target: Please note that this feature is at the time command line only! The Unraid-Kernel-Helper-Plugin has now a basic GUI for creation/deletion of IQNs,FileIO/Block Volumes, LUNs, ACL's. ATTENTION: Always mount a block volume with the path: '/dev/disk/by-id/...' (otherwise you risk data loss)! For instructions on how to create a target read the manuals: Manual Block Volume.txt Manual FileIO Volume.txt ATTENTION: Please read the discription of the variables carefully! If you started the container don't interrupt the build process, the container will automatically shut down if everything is finished. I recommend to open a console window and type in 'docker attach Unraid-Kernel-Helper' (without quotes and replace 'Unraid-Kernel-Helper' with your Container name) to view the log output. (You can also open a log window from the Docker page but this can be verry laggy if you select much build options). The build itself can take very long depending on your hardware but should be done in ~30minutes (some tasks can take very long depending on your hardware, please be patient). Plugin now available (will show all informations about the images/drivers/modules that it can get): https://raw.githubusercontent.com/ich777/unraid-kernel-helper-plugin/master/plugins/Unraid-Kernel-Helper.plg Or simply download it through the CA App This is how the build of the Images is working (simplyfied): The build process begins as soon as the docker starts (you will see the docker image is stopped when the process is finished) Please be sure to set the build options that you need. Use the logs or better open up a Console window and type: 'docker attach Unraid-Kernel-Helper' (without quotes) to also see the log (can be verry laggy in the browser depending on how many components you choose). The whole process status is outlined by watching the logs (the button on the right of the docker). The image is built into /mnt/cache/appdata/kernel/output-VERSION by default. You need to copy the output files to /boot on your USB key manually and you also need to delete it or move it for any subsequent builds. There is a backup copied to /mnt/cache/appdata/kernel/backup-version. Copy that to another drive external to your Unraid Server, that way you can easily copy it straight onto the Unraid USB if something goes wrong. THIS CONTAINER WILL NOT CHANGE ANYTHING TO YOUR EXISTING INSTALLATION OR ON YOUR USB KEY/DRIVE, YOU HAVE TO MANUALLY PUT THE CREATED FILES IN THE OUTPUT FOLDER TO YOUR USB KEY/DRIVE AND REBOOT YOUR SERVER. PLEASE BACKUP YOUR EXISTING USB DRIVE FILES TO YOUR LOCAL COMPUTER IN CASE SOMETHING GOES WRONG! I AM NOT RESPONSIBLE IF YOU BREAK YOUR SERVER OR SOMETHING OTHER WITH THIS CONTAINER, THIS CONTAINER IS THERE TO HELP YOU EASILY BUILD A NEW IMAGE AND UNDERSTAND HOW THIS IS WORKING. UPDATE NOTICE: If a new Update of Unraid is released you have to change the repository in the template to the corresponding build number (I will create the appropriate container as soon as possible) eg: 'ich777/unraid-kernel-helper:6.8.3'. Forum Notice: When something isn't working with or on your server and you make a forum post always include that you use a Kernel built by this container! Note that LimeTech supports no custom Kernels and you should ask in this thread if you are using this specific Kernel when something is not working. CUSTOM_MODE: This is only for Advanced users! In this mode the container will stop right at the beginning and will copy over the build script and the dependencies to build the kernel modules for DVB and joydev in the main directory (I highly recommend using this mode for changing things in the build script like adding patches or other modules to build, connect to the console of the container with: 'docker exec -ti NAMEOFYOURCONTAINER /bin/bash' and then go to the /usr/src directory, also the build script is executable). Note: You can use the nVidia & DVB Plugin from linuxserver.io to check if your driver is installed correctly (keep in mind that some things will display wrong and or not showing up like the driver version in the nVidia Plugin - but you will see the installed grapics cards and also in the DVB plugin it will show that no kernel driver is installed but you will see your installed cards - this is simply becaus i don't know how their plugins work). Thanks to @Leoyzen, klueska from nVidia and linuxserver.io for getting the motivation to look into this how this all works... For safety reasons I recommend you to shutdown all other containers and VM's during the build process especially when building with the nVidia drivers! After you finished building the images i recommend you to delete the container! If you want to build it again please redownload it from the CA App so that the template is always the newest version! Beta Build (the following is a tutorial for v6.9.0): Upgrade to your preferred stock beta version first, reboot and then start building (to avoid problems)! Download/Redownload the template from the CA App and change the following things: Change the repository from 'ich777/unraid-kernel-helper:6.8.3' to 'ich777/unraid-kernel-helper:6.9.0' Select the build options that you prefer Click on 'Show more settings...' Set Beta Build to 'true' (now you can also put in for example: 'beta25' without quotes to automaticaly download Unraid v6.9.0-beta25 and the other steps are not required anymore) Start the container and it will create the folders '/stock/beta' inside the main folder Place the files bzimage bzroot bzmodules bzfirmware in the folder from step 5 (after the start of the container you have 2 minutes to copy over the files, if you don't copy over the files within this 2 mintues simply restart the container and the build will start if it finds all files) (You can get the files bzimage bzroot bzmodules bzfirmware also from the Beta zip file from Limetch or better you first upgrade to that Beta version and then copying over the files from your /boot directory to the directory created in step 5 to avoid problems) !!! Please also note that if you build anything Beta keep an eye on the logs, especially when it comes to building the Kernel (everything before the message '---Starting to build Kernel vYOURKERNELVERSION in 10 seconds, this can take some time, please wait!---' is very important) !!! Here you can download the prebuilt images: Unraid Custom nVidia builtin v6.8.3: Download (nVidia driver: 450.66) Unraid Custom nVidia & DVB builtin v6.8.3: Download (nVidia driver: 450.66 | LE driver: 1.4.0) Unraid Custom nVidia & ZFS builtin v6.8.3: Download (nVidia driver: 450.66 | ZFS version: 0.8.4) Unraid Custom DVB builtin v6.8.3: Download (LE driver: 1.4.0) Unraid Custom ZFS builtin v6.8.3: Download (ZFS version: 0.8.4) Unraid Custom iSCSI builtin v6.8.3: Download (targetcli version: 2.1.53) Manual Block Volume.txt Manual FileIO Volume.txt Unraid Custom nVidia builtin v6.9.0 beta25: Download (nVidia beta driver: 450.66) Unraid Custom nVidia & DVB builtin v6.9.0 beta25: Download (nVidia beta driver: 450.66 | LE driver: 1.4.0) Unraid Custom nVidia & ZFS builtin v6.9.0 beta25: Download (nVidia beta driver: 450.66 | ZFS Build from 'master' branch on Github on 2020.08.19) Unraid Custom ZFS builtin v6.9.0 beta25: Download (ZFS Build from 'master' branch on Github on 2020.07.12) Unraid Custom iSCSI builtin v6.9.0 beta25: Download (targetcli version: 2.1.53) Manual Block Volume.txt Manual FileIO Volume.txt Unraid Custom nVidia builtin v6.9.0 beta29: Download (nVidia beta driver: 455.23.04) Unraid Custom nVidia & DVB builtin v6.9.0 beta29: Download (nVidia beta driver: 455.23.04 | LE driver: 1.4.0) Unraid Custom nVidia & ZFS builtin v6.9.0 beta29: Download (nVidia beta driver: 455.23.04 | ZFS v2.0.0-rc2) Unraid Custom ZFS builtin v6.9.0 beta29: Download (ZFS v2.0.0-rc2) Unraid Custom iSCSI builtin v6.9.0 beta29: Download (targetcli version: 2.1.53) Manual Block Volume.txt Manual FileIO Volume.txt Unraid Custom nVidia builtin v6.9.0 beta30 Download (nVidia driver: 455.28) Unraid Custom nVidia & DVB builtin v6.9.0 beta30: Download (nVidia driver: 455.28 | LE driver: 1.4.0) Unraid Custom nVidia & ZFS builtin v6.9.0 beta30: Download (nVidia driver: 455.28 | ZFS 0.8.5) Unraid Custom ZFS builtin v6.9.0 beta30: Download (ZFS 0.8.5) Unraid Custom iSCSI builtin v6.9.0 beta30: Download (targetcli version: 2.1.53) Manual Block Volume.txt Manual FileIO Volume.txt Notice for Custom pre-built images for Unraid version 6.9.0beta35 and up: Since Unraid changed the game completely with the release of version 6.9.0beta35 and up, so that you can install the Nvidia, DVB and many more other addons to Unraid that I even can't imagine at the time of writing, I will not make or post pre-built images here for the new versions. However I will update the container in general so that you can build your own custom images if you want a 'all in one' solution. (You have to be at least on Unraid 6.9.0beta35 to see the Plugins in the CA App for Nvidia, DVB,...) If you like my work, please consider making a donation
  4. 24 points
    All of us at Lime Technology are very excited to announce Larry Meaney as a new full-time hire. Larry has joined us as a Senior Developer/Project Lead. Here's a little more about Larry: Please help us give Larry aka @ljm42 a warm welcome!
  5. 24 points
    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: support@lime-technology.com. 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
  6. 22 points
    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.
  7. 19 points
    ***Update*** : Apologies, it seems like there was an update to the Unraid forums which removed the carriage returns in my code blocks. This was causing people to get errors when typing commands verbatim. I've fixed the code blocks below and all should be Plexing perfectly now Y =========== Granted this has been covered in a few other posts but I just wanted to have it with a little bit of layout and structure. Special thanks to [mention=9167]Hoopster[/mention] whose post(s) I took this from. What is Plex Hardware Acceleration? When streaming media from Plex, a few things are happening. Plex will check against the device trying to play the media: Media is stored in a compatible file container Media is encoded in a compatible bitrate Media is encoded with compatible codecs Media is a compatible resolution Bandwith is sufficient If all of the above is met, Plex will Direct Play or send the media directly to the client without being changed. This is great in most cases as there will be very little if any overhead on your CPU. This should be okay in most cases, but you may be accessing Plex remotely or on a device that is having difficulty with the source media. You could either manually convert each file or get Plex to transcode the file on the fly into another format to be played. A simple example: Your source file is stored in 1080p. You're away from home and you have a crappy internet connection. Playing the file in 1080p is taking up too much bandwith so to get a better experience you can watch your media in glorious 240p without stuttering / buffering on your little mobile device by getting Plex to transcode the file first. This is because a 240p file will require considerably less bandwith compared to a 1080p file. The issue is that depending on which format your transcoding from and to, this can absolutely pin all your CPU cores at 100% which means you're gonna have a bad time. Fortunately Intel CPUs have a little thing called Quick Sync which is their native hardware encoding and decoding core. This can dramatically reduce the CPU overhead required for transcoding and Plex can leverage this using their Hardware Acceleration feature. How Do I Know If I'm Transcoding? You're able to see how media is being served by playing a first something on a device. Log into Plex and go to Settings > Status > Now Playing As you can see this file is being direct played, so there's no transcoding happening. If you see (throttled) it's a good sign. It just means is that your Plex Media Server is able to perform the transcode faster than is necessary. To initiate some transcoding, go to where your media is playing. Click on Settings > Quality > Show All > Choose a Quality that isn't the Default one If you head back to the Now Playing section in Plex you will see that the stream is now being Transcoded. I have Quick Sync enabled hence the "(hw)" which stands for, you guessed it, Hardware. "(hw)" will not be shown if Quick Sync isn't being used in transcoding. PreRequisites 1. A Plex Pass - If you require Plex Hardware Acceleration Test to see if your system is capable before buying a Plex Pass. 2. Intel CPU that has Quick Sync Capability - Search for your CPU using Intel ARK 3. Compatible Motherboard You will need to enable iGPU on your motherboard BIOS In some cases this may require you to have the HDMI output plugged in and connected to a monitor in order for it to be active. If you find that this is the case on your setup you can buy a dummy HDMI doo-dad that tricks your unRAID box into thinking that something is plugged in. Some machines like the HP MicroServer Gen8 have iLO / IPMI which allows the server to be monitored / managed remotely. Unfortunately this means that the server has 2 GPUs and ALL GPU output from the server passed through the ancient Matrox GPU. So as far as any OS is concerned even though the Intel CPU supports Quick Sync, the Matrox one doesn't. =/ you'd have better luck using the new unRAID Nvidia Plugin. Check Your Setup If your config meets all of the above requirements, give these commands a shot, you should know straight away if you can use Hardware Acceleration. Login to your unRAID box using the GUI and open a terminal window. Or SSH into your box if that's your thing. Type: cd /dev/dri ls If you see an output like the one above your unRAID box has its Quick Sync enabled. The two items were interested in specifically are card0 and renderD128. If you can't see it not to worry type this: modprobe i915 There should be no return or errors in the output. Now again run: cd /dev/dri ls You should see the expected items ie. card0 and renderD128 Give your Container Access Lastly we need to give our container access to the Quick Sync device. I am going to passively aggressively mention that they are indeed called containers and not dockers. Dockers are manufacturers of boots and pants company and have nothing to do with virtualization or software development, yet. Okay rant over. We need to do this because the Docker host and its underlying containers don't have access to anything on unRAID unless you give it to them. This is done via Paths, Ports, Variables, Labels or in this case Devices. We want to provide our Plex container with access to one of the devices on our unRAID box. We need to change the relevant permissions on our Quick Sync Device which we do by typing into the terminal window: chmod -R 777 /dev/dri Once that's done Head over to the Docker Tab, click on the your Plex container. Scroll to the bottom click on Add another Path, Port, Variable Select Device from the drop down Enter the following: Name: /dev/dri Value: /dev/dri Click Save followed by Apply. Log Back into Plex and navigate to Settings > Transcoder. Click on the button to SHOW ADVANCED Enable "Use hardware acceleration where available". You can now do the same test we did above by playing a stream, changing it's Quality to something that isn't its original format and Checking the Now Playing section to see if Hardware Acceleration is enabled. If you see "(hw)" congrats! You're using Quick Sync and Hardware acceleration [emoji4] Persist your config On Reboot unRAID will not run those commands again unless we put it in our go file. So when ready type into terminal: nano /boot/config/go Add the following lines to the bottom of the go file modprobe i915 chmod -R 777 /dev/dri Press Ctrl X, followed by Y to save your go file. And you should be golden!
  8. 19 points
    This is a bug fix and security update release. Due to a security vulnerability discovered in forms-based authentication: ALL USERS ARE STRONGLY ENCOURAGED TO UPGRADE To upgrade: If you are running any 6.4 or later release, click 'Check for Updates' on the Tools/Update OS page. If you are running a pre-6.4 release, click 'Check for Updates' on the Plugins page. If the above doesn't work, navigate to Plugins/Install Plugin, select/copy/paste this plugin URL and click Install: https://s3.amazonaws.com/dnld.lime-technology.com/stable/unRAIDServer.plg Refer also to @ljm42 excellent 6.4 Update Notes which are helpful especially if you are upgrading from a pre-6.4 release. Bugs: If you discover a bug or other issue in this release, please open a Stable Releases Bug Report. Version 6.8.1 2020-01-10 Changes vs. 6.8.0 Base distro: libuv: version 1.34.0 libvirt: version 5.10.0 mozilla-firefox: version 72.0.1 (CVE-2019-17026, CVE-2019-17015, CVE-2019-17016, CVE-2019-17017, CVE-2019-17018, CVE-2019-17019, CVE-2019-17020, CVE-2019-17021, CVE-2019-17022, CVE-2019-17023, CVE-2019-17024, CVE-2019-17025) php: version 7.3.13 (CVE-2019-11044 CVE-2019-11045 CVE-2019-11046 CVE-2019-11047 CVE-2019-11049 CVE-2019-11050) qemu: version 4.2.0 samba: version 4.11.4 ttyd: version 20200102 wireguard-tools: version 1.0.20200102 Linux kernel: version 4.19.94 kernel_firmware: version 20191218_c4586ff (with additional Intel BT firmware) CONFIG_THUNDERBOLT: Thunderbolt support CONFIG_INTEL_WMI_THUNDERBOLT: Intel WMI thunderbolt force power driver CONFIG_THUNDERBOLT_NET: Networking over Thunderbolt cable oot: Highpoint rr3740a: version v1.19.0_19_04_04 oot: Highpoint r750: version v1.2.11-18_06_26 [restored] oot: wireguard: version 0.0.20200105 Management: add cache-busting params for noVNC url assets emhttpd: fix cryptsetup passphrase input network: disable IPv6 for an interface when its settings is "IPv4 only". webgui: Management page: fixed typos in help text webgui: VM settings: fixed Apply button sometimes not working webgui: Dashboard: display CPU load full width when no HT webgui: Docker: show 'up-to-date' when status is unknown webgui: Fixed: handle race condition when updating share access rights in Edit User webgui: Docker: allow to set container port for custom bridge networks webgui: Better support for custom themes (not perfect yet) webgui: Dashboard: adjusted table positioning webgui: Add user name and user description verification webgui: Edit User: fix share access assignments webgui: Management page: remove UPnP conditional setting webgui: Escape shell arg when logging csrf mismatch webgui: Terminal button: give unsupported warning when Edge/MSIE is used webgui: Patched vulnerability in auth_request webgui: Docker: added new setting "Host access to custom networks" webgui: Patched vulnerability in template.php
  9. 18 points
    tldr: If you require hardware support offered by the Linux 5.x kernel then I suggest you remain on 6.8.0-rc7 and wait until 6.9.0-rc1 is published before upgrading. The "unexpected GSO type" bug is looking to be a show stopper for Unraid 6.8 using Linux kernel 5.3 or 5.4 kernel. We can get it to happen easily and quickly simply by having any VM running and then also start a docker App where Network Type has been set to "Custom : br0" (in my case) and I've set a static IP for the container or toggle between setting static IP and letting docker dhcp assign one. There are probably a lot of users waiting for a stable release who will see this issue, and therefore, I don't think we can publish with this bug. The bug does not occur with any 4.19.x or 4.20.x Linux kernel; but does occur with all kernels starting with 5.0. This implies the bug was introduced with some code change in the initial 5.0 kernel. The problem is that we are not certain where to report the bug; it could be a kernel issue or a docker issue. Of course, it could also be something we are doing wrong, since this issue is not reported in any other distro AFAIK. We are continuing investigation and putting together a report to submit either to kernel mailing list or as a docker issue. In any case, an actual fix will probably take quite a bit more time, especially since we are heading into the holidays. Therefore this is what we plan to do: For 6.8: revert kernel to 4.19.87 and publish 6.8.0-rc8. Those currently running stable (6.7.2) will see no loss of functionality because that release is also on 4.19 kernel. Hopefully this will be last or next to last -rc and then we can publish 6.8 stable. Note: we cannot revert to 4.20 kernel because that kernel is EOL and has not had any updates in months. For 6.9: as soon as 6.8 stable is published we'll release 6.9.0-rc1 on next release branch. This will be exactly the same as 6.8 except that we'll update to latest 5.4 kernel (and "unexpected GSO type" bug will be back). We will use the next branch to try and solve this bug. New features, such as multiple pools, will be integrated into 6.10 release, which is current work-in-progress. We'll wait a day or two to publish 6.8-rc8 with reverted kernel in hopes those affected will see this post first.
  10. 18 points
    To upgrade: If you are running any 6.4 or later release, click 'Check for Updates' on the Tools/Update OS page. If you are running a pre-6.4 release, click 'Check for Updates' on the Plugins page. If the above doesn't work, navigate to Plugins/Install Plugin, select/copy/paste this plugin URL and click Install: https://s3.amazonaws.com/dnld.lime-technology.com/stable/unRAIDServer.plg Refer also to @ljm42 excellent 6.4 Update Notes which are helpful especially if you are upgrading from a pre-6.4 release. Bugs: If you discover a bug or other issue in this release, please open a Stable Releases Bug Report. New in Unraid OS 6.8 release: The Update OS tool still downloads the new release zip file to RAM but then extracts directly to USB flash boot device. You will probably notice a slight difference in speed of extract messages. Also the 'sync' command at the end has been replaced with 'sync -f /boot' to prevent spin-up of all devices before the operation is considered complete. Forms based authentication If you have set a root password for your server, when accessing webGUI you'll now see a nice login form. There still is only one user for Unraid so for username enter root. This form should be compatible with all major password managers out there. We always recommend using a strong password. There is no auto-logout implemented yet, please click Logout on menu bar or completely close your browser to logout. Linux kernel We started 6.8 development and initial testing using Linux 5.x kernel. However there remains an issue when VM's and Docker containers using static IP addresses are both running on the same host network interface. This issue does not occur with the 4.19 kernel. We are still studying this issue and plan to address it in the Unraid 6.9 release. Changes to the kernel include: Update to 4.19.88 Include latest Intel microcode for yet another hardware vulnerability mitigation. Default scheduler now 'mq-deadline', but this can be changed via new Settings/Disk Settings/Scheduler setting. Enabled Huge Page support, though no UI control yet. binfmt_misc support. Fix chelsio missing firmware. Added oot: Realtek r8125: version 9.002.02 Removed Highpoint r750 driver [does not work] md/unraid driver Introduced "multi-stream" support: Reads on devices which are not being written should run at full speed. In addition, if you have set the md_write_method tunable to "reconstruct write", then while writing, if any read streams are detected, the write method is switched to "read/modifywrite". Parity sync/check should run at full speed by default. Parity sync/check is throttled back in presence of other active streams. The "stripe pool" resource is automatically shared evenly between all active streams. As a result got rid of some Tunables: md_sync_window md_sync_thresh and added some tunables: md_queue_limit md_sync_limit [-rc2] md_scheduler Please refer to Settings/Disk Settings help text for description of these settings. WireGuard® support - available as a plugin via Community Apps. Our WireGuard implementation and UI is still a work-in-process; for this reason we have made this available as a plugin, though the latest WireGuard module is included in our Linux kernel. I want to give special thanks to @bonienl who wrote the plugin with lots of guidance from @ljm42 - thank you! I also should give a shout out to @NAS who got us rolling on this. If you don't know about WireGuard it's something to look into! Note: WireGuard is a registered trademark of Jason A. Donenfeld. Guide here: WS-Discovery support - Finally you can get rid of SMBv1 and get reliable Windows network discovery. This feature is configured on the Settings/SMB Settings page and enabled by default. Also on same settings page is Enable NetBIOS setting. This is enabled by default, however if you no longer have need for NetBIOS discovery you can turn it off. When turned off, Samba is configured to accept only SMBv2 protocol and higher. Added mDNS client support in Unraid OS. This means, for example, from an Unraid OS terminal session to ping another Unraid OS server on your network you can use (e.g., 'tower'): ping tower.local instead of ping tower Note the latter will still work if you have NetBIOS enabled. User Share File System (shfs) changes: Integrated FUSE-3 - This should increase performance of User Share File System. Fixed bug with hard link support. Previously a 'stat' on two directory entries referring to same file would return different i-node numbers, thus making it look like two independent files. This has been fixed however there is a config setting on Settings/Global Share Settings called "Tunable (support hard links)". The default is Yes, but with certain very old media and DVD players which access shares via NFS, you may need to set this to No. Note: if you have custom config/extra.cfg file, get rid of any lines specifying additional FUSE options unless you know they are compatible with FUSE-3. Other improvements/bug fixes: Fixed SQLite DB Corruption bug. Format - during Format any running parity sync/check is automatically Paused and then resumed upon Format completion. Encryption - an entered passphrase is not saved to any file. Fixed bug where multi-device btrfs pool was leaving metadata set to dup instead of raid1. Fixed bug where quotes were not handled properly in passwords. Numerous base package updates including updating PHP to version 7.3.x, Samba to version 4.11.x. Several other small bug fixes and improvements. Known Issues and Other Errata Some users have reported slower parity sync/check rates for very wide arrays (20+ devices) vs. 6.7 and earlier releases - we are still studying this problem. In another step toward better security, the USB flash boot device is configured so that programs and scripts residing there cannot be directly executed (this is because the 'x' bit is set now only for directories). Commands placed in the 'go' file still execute because during startup, that file is copied to /tmp first and then executed from there. If you have created custom scripts you may need to take a similar approach. AFP is now deprecated and we plan to remove support. A note on password strings Password strings can contain any character however white space (space and tab characters) is handled specially: all leading and trailing white space is discarded multiple embedded white space is collapsed to a single space character. By contrast, encryption passphrase is used exactly as-is. Version 6.8.0 2019-12-10 Base distro: aaa_elflibs: version 15.0 build 16 acpid: version 2.0.32 adwaita-icon-theme: version 3.34.3 at-spi2-atk: version 2.34.1 at-spi2-core: version 2.34.0 at: version 3.2.1 atk: version 2.34.1 bash: version 5.0.011 binutils: version 2.33.1 btrfs-progs: version 5.4 bzip2: version 1.0.8 ca-certificates: version 20191130 cifs-utils: version 6.9 cpio: version 2.13 cryptsetup: version 2.2.2 curl: version 7.67.0 dbus-glib: version 0.110 dbus: version 1.12.16 dhcpcd: version 8.1.2 docker: version 19.03.5 e2fsprogs: version 1.45.4 ebtables: version 2.0.11 encodings: version 1.0.5 etc: version 15.0 ethtool: version 5.3 expat: version 2.2.9 file: version 5.37 findutils: version 4.7.0 freetype: version 2.10.1 fuse3: version 3.6.2 gdbm: version 1.18.1 gdk-pixbuf2: version 2.40.0 git: version 2.24.0 glib2: version 2.62.3 glibc-solibs: version 2.30 glibc-zoneinfo: version 2019c glibc: version 2.30 glu: version 9.0.1 gnutls: version 3.6.11.1 gtk+3: version 3.24.13 harfbuzz: version 2.6.4 haveged: version 1.9.8 hostname: version 3.23 hwloc: version 1.11.13 icu4c: version 65.1 intel-microcode: version 20191115 iproute2: version 5.4.0 iptables: version 1.8.4 iputils: version 20190709 irqbalance: version 1.6.0 kernel-firmware: version 20191118_e8a0f4c keyutils: version 1.6 less: version 551 libICE: version 1.0.10 libX11: version 1.6.9 libXi: version 1.7.10 libXt: version 1.2.0 libarchive: version 3.4.0 libcap-ng: version 0.7.10 libcroco: version 0.6.13 libdrm: version 2.4.99 libedit: version 20191025_3.1 libepoxy: version 1.5.4 libevdev: version 1.7.0 libevent: version 2.1.11 libgcrypt: version 1.8.5 libgudev: version 233 libidn2: version 2.3.0 libjpeg-turbo: version 2.0.3 libnftnl: version 1.1.5 libnl3: version 3.5.0 libpcap: version 1.9.1 libpciaccess: version 0.16 libpng: version 1.6.37 libpsl: version 0.21.0 librsvg: version 2.46.4 libseccomp: version 2.4.1 libssh2: version 1.9.0 libtasn1: version 4.15.0 libusb: version 1.0.23 libvirt-php: version 20190803 libvirt: version 5.8.0 (CVE-2019-10161, CVE-2019-10166, CVE-2019-10167, CVE-2019-10168) libwebp: version 1.0.3 libxml2: version 2.9.10 libxslt: version 1.1.34 libzip: version 1.5.2 lm_sensors: version 3.6.0 logrotate: version 3.15.1 lsof: version 4.93.2 lsscsi: version 0.30 lvm2: version 2.03.07 lz4: version 1.9.1 mkfontscale: version 1.2.1 mozilla-firefox: version 71.0 (CVE-2019-11751, CVE-2019-11746, CVE-2019-11744, CVE-2019-11742, CVE-2019-11736, CVE-2019-11753, CVE-2019-11752, CVE-2019-9812, CVE-2019-11741, CVE-2019-11743, CVE-2019-11748, CVE-2019-11749, CVE-2019-5849, CVE-2019-11750, CVE-2019-11737, CVE-2019-11738, CVE-2019-11747, CVE-2019-11734, CVE-2019-11735, CVE-2019-11740, CVE-2019-11754, CVE-2019-9811, CVE-2019-11711, CVE-2019-11712, CVE-2019-11713, CVE-2019-11714, CVE-2019-11729, CVE-2019-11715, CVE-2019-11716, CVE-2019-11717, CVE-2019-1 1718, CVE-2019-11719, CVE-2019-11720, CVE-2019-11721, CVE-2019-11730, CVE-2019-11723, CVE-2019-11724, CVE-2019-11725, CVE-2019-11727, CVE-2019-11728, CVE-2019-11710, CVE-2019-11709) (CVE-2018-6156, CVE-2019-15903, CVE-2019-11757, CVE-2019-11759, CVE-2019-11760, CVE-2019-11761, CVE-2019-11762, CVE-2019-11763, CVE-2019-11765, CVE-2019-17000, CVE-2019-17001, CVE-2019-17002, CVE-2019-11764) (CVE-2019-11756, CVE-2019-17008, CVE-2019-13722, CVE-2019-11745, CVE-2019-17014, CVE-2019-17009, CVE-2019-17010, CVE-2019-17005, CVE-2019-17011, CVE-2019-17012, CVE-2019-17013) nano: version 4.6 ncurses: version 6.1_20191026 net-tools: version 20181103_0eebece nettle: version 3.5.1 network-scripts: version 15.0 nghttp2: version 1.40.0 nginx: version 1.16.1 (CVE-2019-9511, CVE-2019-9513, CVE-2019-9516) nodejs: version 10.16.3 nss-mdns: version 0.14.1 ntp: version 4.2.8p13 openldap-client: version 2.4.48 openssh: version 8.1p1 openssl-solibs: version 1.1.1d openssl: version 1.1.1d p11-kit: version 0.23.18.1 pcre2: version 10.34 php: version 7.3.12 (CVE-2019-11042, CVE-2019-11041) (CVE-2019-11043) pixman: version 0.38.4 pkgtools: version 15.0 build 28 procps-ng: version 3.3.15 qemu: version 4.1.1 (CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091) (CVE-2019-14378, CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-12068, CVE-2019-11091) qrencode: version 4.0.2 rpcbind: version 1.2.5 rsyslog: version 8.1908.0 samba: version 4.11.3 (CVE-2019-10197) (CVE-2019-10218, CVE-2019-14833, CVE-2019-14847) (CVE-2019-14861, CVE-2019-14870) sdparm: version 1.10 sessreg: version 1.1.2 setxkbmap: version 1.3.2 sg3_utils: version 1.44 shadow: version 4.7 shared-mime-info: version 1.15 sqlite: version 3.30.1 sudo: version 1.8.29 sysvinit-scripts: version 2.1 sysvinit: version 2.96 talloc: version 2.3.0 tdb: version 1.4.2 tevent: version 0.10.1 ttyd: version 20191025 usbutils: version 012 util-linux: version 2.34 wget: version 1.20.3 wireguard: version 0.0.20191206 wsdd: version 20180618 build 2 xauth: version 1.1 xclock: version 1.0.9 xfsprogs: version 5.3.0 xkeyboard-config: version 2.28 xorg-server: version 1.20.6 xrandr: version 1.5.1 xterm: version 351 xwininfo: version 1.1.5 zstd: version 1.4.4 Linux kernel: version 4.19.88 CONFIG_BINFMT_MISC: Kernel support for MISC binaries CONFIG_CGROUP_NET_PRIO: Network priority cgroup CONFIG_DEBUG_FS: Debug Filesystem CONFIG_DUMMY: Dummy net driver support CONFIG_HUGETLBFS: HugeTLB file system support CONFIG_ICE: Intel(R) Ethernet Connection E800 Series Support CONFIG_IGC: Intel(R) Ethernet Controller I225-LM/I225-V support CONFIG_IPVLAN: IP-VLAN support CONFIG_IPVTAP: IP-VLAN based tap driver CONFIG_IP_VS: IP virtual server support CONFIG_IP_VS_NFCT: Netfilter connection tracking CONFIG_IP_VS_PROTO_TCP: TCP load balancing support CONFIG_IP_VS_PROTO_UDP: UDP load balancing support CONFIG_IP_VS_RR: round-robin scheduling CONFIG_MLX5_CORE_IPOIB: Mellanox 5th generation network adapters (connectX series) IPoIB offloads support CONFIG_NETFILTER_XT_MATCH_IPVS: "ipvs" match support CONFIG_NET_CLS_CGROUP: Control Group Classifier CONFIG_SCSI_MQ_DEFAULT: SCSI: use blk-mq I/O path by default CONFIG_SCSI_SMARTPQI: Microsemi PQI Driver CONFIG_WIREGUARD: IP: WireGuard secure network tunnel chelsio: add missing firmware change schedulers from modules to built-ins default scheduler now mq-deadline md/unraid: version 2.9.13 (multi-stream support, do not fail read-ahead, more tunables) increase BLK_MAX_REQUEST_COUNT from 16 to 32 oot: Highpoint rr3740a: version: v1.17.0_18_06_15 oot: Highpoint rsnvme: version v1.2.16_19_05_06 oot: Highpoint r750 removed (does not work) oot: Intel ixgbe: version 5.6.5 oot: Realtek r8125: version 9.002.02 oot: Tehuti tn40xx: version 0.3.6.17.2 oot: Tehuti tn40xx: add x3310fw_0_3_4_0_9445.hdr firmware Management: add 'scheduler' tunable for array devices auto-mount hugetlbfs to support kernel huge pages emhttpd: fix improper handling of embedded quote characters in a password emhttpd: correct footer notifications emhttpd: do not write /root/keyfile if encryption passphrase provided via webGUI emhttpd: properly handle encoded passwords emhttpd: solve deadlock issue with 'emcmd' called from a plugin extract OS upgrade directly to USB flash fix btrfs bug where converting from single to multiple pool did not balance metadata to raid1, and converting from multiple to single did not balance metadata back to single. fix shfs hard link initially reported as enabled but not actually enabled fstab: mount USB flash boot device with root-only access nginx.conf: configure all nginx worker threads to run as 'root'. nginx: disable php session expiration php: set very long session timeout samba: if netbios enabled, set 'server min protocol = NT1' shfs: fix bug not accounting for device(s) not mounted yet shfs: support FUSE3 API changes; hard links report same st_ino; hard link support configurable start/stop WireGuard upon server start/shutdown support WS-Discovery method support disabling NetBIOS, and set Samba 'min server procotol' and 'min client protocol' to SMB2 if disabled support forms-based authentication support mDNS local name resolution via avahi unRAIDServer.plg (update OS) now executes 'sync -f /boot' instead of full sync at end of update webgui: Add share access to user edit webgui: Add shares: slashes are not allowed in share name webgui: Add support for the self-hosted Gotify notification agent. webgui: Added 'F1' key to toggle help text webgui: Added AFP deprecated notice webgui: Added UPnP to access script (to support WireGuard plugin) webgui: Added VM XML files to diagnostics webgui: Added cache and disk type to shares page webgui: Added conditional UPnP setting on Management page webgui: Aligned management page layout webgui: Allow Safari to use websockets webgui: Allow outside click to close popups webgui: Change PluginHelpers download to be PHP Curl webgui: Change dashbord link for mb/mem webgui: Changed config folder of TELEGRAM webgui: Dashboard: WG tunnel handshake in days when longer than 24 hours webgui: Dashboard: add up/down arrows to VPN tunnel traffic webgui: Dashboard: adjust column width for themes azure/gray webgui: Dashboard: fix WG direction arrows webgui: Dashboard: fixed user write + read counts webgui: Dashboard: show titles without text-transform webgui: Diagnostics: Adjust for timezone from webGUI webgui: Diagnostics: Remove OSK info from VM xml webgui: Do not display error if docker log files manually deleted webgui: Docker and VM settings: validate path and name input webgui: Docker: fixed multi container updates display oddity webgui: Enable notifications by default webgui: Enhanced display of network settings webgui: Ensure spinner always ontop webgui: Expanded help for Use Cache setting webgui: Fix custom case png not surviving reboot webgui: Fixed diagnostics errors when array was never started webgui: Fixed docker container update state webgui: Fixed misalignment of absent disk on Main page webgui: Fixed popup window in foreground webgui: Fixed typo in help text webgui: Fixed typo in shares settings webgui: Fixed: footer always on foreground webgui: Fixed: undo cleanup of disk.png webgui: Font, Icon and image cleanup webgui: If a page is loaded via https, prevent it from loading resources via http (ie, block mixed content) webgui: Improve Use Cache option webgui: Integrate CAs Plugin Helper webgui: Made notify script compatible with 6.8 new security scheme webgui: Main page: consolidate spin up/down action and device status into one webgui: Modified notify script to allow overriding email recipients in notification settings webgui: Only create session when user successfully logs in; also enable session.use_strict_mode to prevent session fixation attacks webgui: Open banner system to 3rd party apps webgui: Plugin Helpers: Follow redirects on downloads webgui: Rename docker repositories tab to template repositories webgui: Revamp Banner Warning System webgui: Select case correction + replace MD1510 for AVS-10/4 webgui: Standardize on lang="en" webgui: Submit passphrases and passwords in base64 format webgui: Support wireguard plugin in download.php webgui: Switch download routine to be PHP Curl webgui: Syslog: allow up to 5 digits port numbers webgui: Telegram notification agent: enable group chat IDs, update helper description webgui: Unraid fonts and cases update webgui: Update ArrayDevices.page help text webgui: Upgrade noVNC to git commit 9f557f5 webgui: Use complete HTML documents in popups webgui: Warning alert for Format operations webgui: dockerMan - Deprecate TemplateURL webgui: dockerMan: Redownload Icon if URL changes webgui: other minor text corrections webgui: show warning on login page when browser cookies are disabled webgui: support changed tunables on Disk Settings page
  11. 17 points
    I’ve been around a little while. I always follow the boards even though I have very little life time to give to being active in the community anymore. I felt the need to post to say I can completely appreciate how the guys at @linuxserver.io feel. I was lucky enough to be apart of the team @linuxserver.iofor a short while and I can personally attest to how much personal time and effort they put into development, stress testing and supporting their developments. While @limetech has developed a great base product i think it’s right to acknowledge that much of the popularity and success of the product is down as much to community development and support (which is head and shoulders above by comparison) as it is to the work of the company. As a now outsider looking in, my personal observation is that the use of unRAID exploded due to the availability of stable, regularly updated media apps like Plex (the officially supported one was just left to rot) and then exploded again with the emergence of the @linuxserver.ionVidia build and the support that came with it. Given the efforts of the community and groups like @linuxserver.io is even used in unRAID marketing I feel this is a show of poor form. I feel frustrated at Tom’s “I didn’t know I needed permission ....” comment as it isn’t about that. It’s about respect and communication. A quick “call” to the @linuxserver.io team to let them know of the plan (yes I know the official team don’t like sharing plans at risk of setting expectations they then won’t meet) to (even privately) acknowledge the work that has (and continues to) contribute to the success of unRAID and let them be a part of it would have cost Nothing but would have been worth so much. I know the guys would have been supporting too. I hope the two teams can work it out and that @limetech don’t forget what (and who) helped them get to where they are and perhaps looks at other companies who have alienated their community through poor decisions and communication. Don’t make this the start of a slippery slide.
  12. 17 points
    v6.8.2 uploaded. Delayed for a few reasons, had problems (and still do) with the nvidia container runtime, worked around it in the end, but not a long term solution looking forward, I'm working like a dog at the moment as my current real life job finishes in 2 days and I'm having to put a ton of extra hours in, wife a bit ungainly at the moment as very heavily pregnant so I'm having to do a bit more for our existing beast, and to add to that bass_rock has been away for work, so kind of a perfect storm of not having much time to sit down with this, although I have been trying to get it working every chance I've had. Anyways, I've tested this version, think everything is working, and I believe all the out of tree drivers are squared away. Last version (v6.8.1) might have been missing the Intel 1gb driver as I hadn't realised that it was different to the 10gb driver.
  13. 16 points
    I've have been following this and the other thread with very mixed feelings and I feel the community is unjustly hard towards @limetech. Sure some things could have been handled better, yet I keep the feelings that the bigger injustice is not actually committed by him. In order to understand things better and to see things from a different perspective I personally like to make analogies. Sometimes it gives different insights into situations. And I cam up with the following for this one: We have 3 parties here, The parent (@limetech), the uncle (@CHBMB and the like) and the kid (the community). Now the situation is that the kid is asking the parent for this shiny new toy, but for whatever reason the parent is not buying the kid the toy. Maybe it is to expensive, maybe he is waiting for the birthday, whatever.. However, the uncle who hears the kid decided to get the kid this new toy, because he loved the kid and wants to please the kid. Fast forward and the parents sees that the kid really loved the toy but unfortunately the toy has some sharp edges and the parent is afraid the kid might hurt himself hence the parent decided to order a better and safer version of the toy. However, when the parent tells the kid it ordered this new toy the uncle hears the parent and flies into a rage because the parent did not tell the uncle that he/she was going to buy the new toy and the uncle thinks the parents is ungrateful because he/she did not even thank the uncle. In his rage therefore the uncle takes the toy away from the kid even before the new toy arrived (it is after all still in beta). Not only that but takes away the other toys he got the kid as well and says he is never going to give the kid any more toys. All this to punish the parent. Now with this analogy, ask yourself. Is the reaction of @CHBMB (the uncle) proportionate and justified? Does a parent (@limetech) need to inform the uncle of these kind of things? Sure it is nice, but is it really needed? Do you think it is right for the uncle to punish the kid? Should the parent even be grateful that the uncle presents the kid a toy with sharp edges (I know I wouldn't). The only one the uncle should expect thanks from i.m.o is the kid. The community is and was grateful. Yet @CHBMB is the one who decided to punish the community and take away their toy because of his hurt feelings. Yet the only one who gets shit is @limetech. If I where him I would be more than a little pissed and disappointment and I think it shows in his messages. Please read my analogy again and ask yourself who in the story did anything to hurt the kid? The parent or the uncle? And please also think about the fact that we have no way of knowing if @limetech was not going to thanks @CHBMB for the work in an official release note, which this wasn't. Now I do think the parent should have said something to the uncle. And I also am a bit disappointment to learn that even though UnRaid builds heavy on the community there is no special channel in place to facilitate communication with reliable community develops. Considering how well the development of both UnRaid and the community add-ons go together I kind of assumes something was already in place. However it seems this is something that is considered and worked on now. But in everything that happened, this simple miscommunication seems far the lesser evil here. And I do think it might be good that the community asks itself again who really is to blame for taking away it's shining toy with sharp edges and if it is reasonable to have this reaction. But that's just my 2 cents.
  14. 16 points
    Hey Guys, First of all, I know that you're all very busy on getting version 6.8 out there, something I'm very much waiting on as well. I'm seeing great progress, so thanks so much for that! Furthermore I won't be expecting this to be on top of the priority list, but I'm hoping someone of the developers team is willing to invest (perhaps after the release). Hardware and software involved: 2 x 1TB Samsung EVO 860, setup with LUKS encryption in BTRFS RAID1 pool. ### TLDR (but I'd suggest to read on anyway 😀) The image file mounted as a loop device is causing massive writes on the cache, potentially wearing out SSD's quite rapidly. This appears to be only happening on encrypted caches formatted with BTRFS (maybe only in RAID1 setup, but not sure). Hosting the Docker files directory on /mnt/cache instead of using the loopdevice seems to fix this problem. Possible idea for implementation proposed on the bottom. Grateful for any help provided! ### I have written a topic in the general support section (see link below), but I have done a lot of research lately and think I have gathered enough evidence pointing to a bug, I also was able to build (kind of) a workaround for my situation. More details below. So to see what was actually hammering on the cache I started doing all the obvious, like using a lot of find commands to trace files that were written to every few minutes and also used the fileactivity plugin. Neither was able trace down any writes that would explain 400 GBs worth of writes a day for just a few containers that aren't even that active. Digging further I moved the docker.img to /mnt/cach/system/docker/docker.img, so directly on the BTRFS RAID1 mountpoint. I wanted to check whether the unRAID FS layer was causing the loop2 device to write this heavy. No luck either. This gave me a situation I was able to reproduce on a virtual machine though, so I started with a recent Debian install (I know, it's not Slackware, but I had to start somewhere ☺️). I create some vDisks, encrypted them with LUKS, bundled them in a BTRFS RAID1 setup, created the loopdevice on the BTRFS mountpoint (same of /dev/cache) en mounted it on /var/lib/docker. I made sure I had to NoCow flags set on the IMG file like unRAID does. Strangely this did not show any excessive writes, iotop shows really healthy values for the same workload (I migrated the docker content over to the VM). After my Debian troubleshooting I went back over to the unRAID server, wondering whether the loopdevice is created weirdly, so I took the exact same steps to create a new image and pointed the settings from the GUI there. Still same write issues. Finally I decided to put the whole image out of the equation and took the following steps: - Stopped docker from the WebGUI so unRAID would properly unmount the loop device. - Modified /etc/rc.d/rc.docker to not check whether /var/lib/docker was a mountpoint - Created a share on the cache for the docker files - Created a softlink from /mnt/cache/docker to /var/lib/docker - Started docker using "/etc/rd.d/rc.docker start" - Started my BItwarden containers. Looking into the stats with "iotstat -ao" I did not see any excessive writing taking place anymore. I had the containers running for like 3 hours and maybe got 1GB of writes total (note that on the loopdevice this gave me 2.5GB every 10 minutes!) Now don't get me wrong, I understand why the loopdevice was implemented. Dockerd is started with options to make it run with the BTRFS driver, and since the image file is formatted with the BTRFS filesystem this works at every setup, it doesn't even matter whether it runs on XFS, EXT4 or BTRFS and it will just work. I my case I had to point the softlink to /mnt/cache because pointing it /mnt/user would not allow me to start using the BTRFS driver (obviously the unRAID filesystem isn't BTRFS). Also the WebGUI has commands to scrub to filesystem inside the container, all is based on the assumption everyone is using docker on BTRFS (which of course they are because of the container 😁) I must say that my approach also broke when I changed something in the shares, certain services get a restart causing docker to be turned off for some reason. No big issue since it wasn't meant to be a long term solution, just to see whether the loopdevice was causing the issue, which I think my tests did point out. Now I'm at the point where I would definitely need some developer help, I'm currently keeping nearly all docker container off all day because 300/400GB worth of writes a day is just a BIG waste of expensive flash storage. Especially since I've pointed out that it's not needed at all. It does defeat the purpose of my NAS and SSD cache though since it's main purpose was hosting docker containers while allowing the HD's to spin down. Again, I'm hoping someone in the dev team acknowledges this problem and is willing to invest. I did got quite a few hits on the forums and reddit without someone actually pointed out the root cause of issue. I missing the technical know-how to troubleshoot the loopdevice issues on a lower level, but have been thinking on possible ways to implement a workaround. Like adjusting the Docker Settings page to switch off the use of a vDisk and if all requirements are met (pointing to /mnt/cache and BTRFS formatted) start docker on a share on the /mnt/cache partition instead of using the vDisk. In this way you would still keep all advantages of the docker.img file (cross filesystem type) and users who don't care about writes could still use it, but you'd be massively helping out others that are concerned over these writes. I'm not attaching diagnostic files since they would probably not point out the needed. Also if this should have been in feature requests, I'm sorry. But I feel that, since the solution is misbehaving in terms of writes, this could also be placed in the bugreport section. Thanks though for this great product, have been using it so far with a lot of joy! I'm just hoping we can solve this one so I can keep all my dockers running without the cache wearing out quick, Cheers!
  15. 15 points
    I come here to see what's new in development and find that there is a big uproar. Hate to say it, but I've been here a long time and community developers come and go and that's just the way it is. This unRAID product opens the door to personalizations, both private and shared. Community developers do leave because they feel that unRAID isn't going in the direction they want it to go or that the unRAID developers aren't listening to them even though there is no obligation to do so. Some leave in a bigger fuss than others. The unRAID developers do the best they can at trying to create a product that will do what the users want. They also do their best to support the product and the community development. The product is strong and the community support is strong and new people willing to put in time supporting it will continue to appear. Maybe some hint of what was coming might have eased tensions, but I just can't get behind users taking their ball and going home because unRAID development included something they used to personally support. That evolution has happened many times over the years, both incrementally and in large steps. That's the nature of this unRAID appliance type OS as it gets developed. There is no place for lingering bad feelings and continuing resentful posts. Hopefully, the people upset can realize that the unRAID developers are simply trying to create a better product, that they let you update for free, without any intent to purposely stomp on community developers.
  16. 15 points
    When my job, wife, daughter and sleep allow me to fit it in. For crying out loud, stop asking people. It's ready when it's ready. Now if you'll excuse me I have a game of hide and seek to play with my daughter. Sent from my Mi A1 using Tapatalk
  17. 14 points
    New in this release: GPU Driver Integration Unraid OS now includes selected in-tree GPU drivers: ast (Aspeed), i915 (Intel), amdgpu and radeon (AMD). These drivers are blacklisted by default via 'conf' files in /etc/modprobe.d: /etc/modprobe.d/ast.conf /etc/modprobe.d/amdgpu.conf /etc/modprobe.d/i915.conf /etc/modprobe.d/radeon.conf Each of these files has a single line which blacklists the driver, preventing it from being loaded by the Linux kernel. However it is possible to override the settings in these files by creating the directory 'config/modprobe.d' on your USB flash boot device and then creating the same named-file in that directory. For example, to unblacklist amdgpu type these commands in a Terminal session: mkdir /boot/config/modprobe.d touch /boot/config/modprobe.d/amdgpu.conf When Unraid OS boots, before the Linux kernel executes device discovery, we copy any files from /boot/config/modprobe.d to /etc/modprobe.d. Since amdgpu.conf on the flash is an empty file, it will effectively cancel the driver from being blacklisted. This technique can be used to set boot-time options for any driver as well. Better Support for Third Party Drivers Recall that we distribute Linux modules and firmware in separate squashfs files which are read-only mounted at /lib/modules and /lib/firmware. We now set up an overlayfs on each of these mount points, making it possible to install 3rd party modules at boot time, provided those modules are built against the same kernel version. This technique may be used by Community Developers to provide an easier way to add modules not included in base Unraid OS: no need to build custom bzimage, bzmodules, bzfirmware and bzroot files. To go along with the other GPU drivers included in this release, we have created a separate installable Nvidia driver package. Since each new kernel version requires drivers to be rebuilt, we have set up a feed that enumerates each driver available with each kernel. The easiest way to install the Nvdia driver, if you require it, is to make use of a plugin provided by Community member @ich777. This plugin uses the feed to install the correct driver for the currently running kernel. A big thank you! to @ich777 for providing assistance and coding up the the plugin: Linux Kernel This release includes Linux kernel 5.8.18. We realize the 5.8 kernel has reached EOL and we are currently busy upgrading to 5.9. Version 6.9.0-beta35 2020-11-12 (vs -beta30) Base distro: aaa_elflibs: version 15.0 build 25 brotli: version 1.0.9 build 2 btrfs-progs: version 5.9 ca-certificates: version 20201016 curl: version 7.73.0 dmidecode: version 3.3 ethtool: version 5.9 freetype: version 2.10.4 fuse3: version 3.10.0 git: version 2.29.1 glib2: version 2.66.2 glibc-solibs: version 2.30 build 2 glibc-zoneinfo: version 2020d glibc: version 2.30 build 2 iproute2: version 5.9.0 jasper: version 2.0.22 less: version 563 libcap-ng: version 0.8 build 2 libevdev: version 1.10.0 libgcrypt: version 1.8.7 libnftnl: version 1.1.8 librsvg: version 2.50.1 libwebp: version 1.1.0 build 3 libxml2: version 2.9.10 build 3 lmdb: version 0.9.27 nano: version 5.3 ncurses: version 6.2_20201024 nginx: version 1.19.4 ntp: version 4.2.8p15 build 3 openssh: version 8.4p1 build 2 pam: version 1.4.0 build 2 rpcbind: version 1.2.5 build 2 samba: version 4.12.9 (CVE-2020-14318 CVE-2020-14318 CVE-2020-14318) talloc: version 2.3.1 build 4 tcp_wrappers: version 7.6 build 3 tdb: version 1.4.3 build 4 tevent: version 0.10.2 build 4 usbutils: version 013 util-linux: version 2.36 build 2 vsftpd: version 3.0.3 build 7 xfsprogs: version 5.9.0 xkeyboard-config: version 2.31 xterm: version 361 Linux kernel: version 5.8.18 added GPU drivers: CONFIG_DRM_RADEON: ATI Radeon CONFIG_DRM_RADEON_USERPTR: Always enable userptr support CONFIG_DRM_AMDGPU: AMD GPU CONFIG_DRM_AMDGPU_SI: Enable amdgpu support for SI parts CONFIG_DRM_AMDGPU_CIK: Enable amdgpu support for CIK parts CONFIG_DRM_AMDGPU_USERPTR: Always enable userptr write support CONFIG_HSA_AMD: HSA kernel driver for AMD GPU devices kernel-firmware: version 20201005_58d41d0 md/unraid: version 2.9.16: correction recording disk info with array Stopped; remove 'superblock dirty' handling oot: Realtek r8152: version 2.14.0 Management: emhttpd: fix 'auto' setting where pools enabled for user shares should not be exported emhttpd: permit Erase of 'DISK_DSBL_NEW' replacement devices emhtptd: track clean/unclean shutdown using file 'config/forcesync' emhttpd: avoid unnecessarily removing mover.cron file modprobe: blacklist GPU drivers by default, config/modprobe.d/* can override at boot samba: disable aio by default startup: setup an overlayfs for /lib/modules and /lib/firmware webgui: pools not enabled for user shares should not be selectable for cache webgui: Add pools information to diagnostics webgui: vnc: add browser cache busting webgui: Multilanguage: Fix unable to delete / edit users webgui: Prevent "Add" reverting to English when adding a new user with an invalid username webgui: Fix Azure / Gray Switch Language being cut-off webgui: Fix unable to use top right icons if notifications present webgui: Changed: Consistency between dashboard and docker on accessing logs webgui: correct login form wrong default case icon displayed webgui: set 'mid-tower' default case icon webgui: fix: jGrowl covering buttons webgui: New Perms: Support multi-cache pools webgui: Remove WG from Dashboard if no tunnels defined webgui: dockerMan: Allow readmore in advanced view webgui: dockerMan: Only allow name compatible with docker
  18. 14 points
    I do not use any of these unofficial builds, nor do i know what they are about and what features they provide that are not included in stock unraid. That being said, i still feel that devs that release them have a point. I think the main issue are these statements by @limetech : "Finally, we want to discourage "unofficial" builds of the bz* files." which are corroborated by the account of the 2019 pm exchange: "concern regarding the 'proliferation of non-stock Unraid kernels, in particular people reporting bugs against non-stock builds.'" Yes technically its true that bug reports based on unofficial builds complicate matters. Also its maybe frustrating that people are reluctant to go the extra mile to go back to stock unraid and try to reproduce the error there. Especially since they might be convinced (correctly or not) it has nothing to do with the unoffial build. Granted from an engineers point of view that might be seen as a nuisance. But from a customer driven business point of view its a self destructive perspective. Obviously these builds fill a need that unraid could not, or else they would not exist and there wouldn't be enough people using them to be a "bug hunting" problem in the first place. They expand unraids capabilities, bring new customers to unraid, demonstrate a lively and active community and basically everything i love about unraid. I think @limetech did not mean it in that way, but i can fully see how people who poured a lot of energy and heart into the unraid ecosystem might perceive it that way. I think if you would have said instead: "Finally we incorporated these new features x,y, and z formerly only available in the builds by A, B and C. Thanks again for your great work A,B and C have being doing for a long while now and for showing us in what way we can enhance unraid for our customers. I took a long time, but now its here. It should also make finding bugs more easy, as many people can now use the official builds." then everybody would have been happy. I think its probably a misunderstanding. I can't really imagine you really wanting to discourage the community from making unraid reach out to more user.
  19. 14 points
    You've obviously got some ideas, why not do it? Problem is I see time and time again, is people keep telling us what we should be doing and how quick we should be doing it, now, don't be offended because this is a general observation, rather than personal. It's ten to one in the morning, I've just got back from work, I have a toddler that is going to get up in about five hours, my wife is heavily pregnant, Unraid Nvidia and beta testing just isn't up there in my list of priorities at this point. I've already looked at it and I need to look at compiling the newly added WireGuard out of tree driver. I will get around to it, but when I can. And if that means some Unraid users have to stick on v6.8.0 for a week or two then so be it, or, alternatively, forfeit GPU transcoding for a week or two, then so be it. I've tried every way I could when I was developing this to avoid completely repacking Unraid, I really did, nobody wanted to do that less than me. But, if we didn't do it this way, then we just saw loads of seg faults. I get a bit annoyed by criticism of turnaround time, because, as this forum approaches 100,000 users, how many actually give anything back? And of all the people who tell us how we should be quicker, how many step up and do it themselves? TL:DR It'll be ready when it's ready, not a moment sooner, and if my wife goes into labour, well, probably going to get delayed. My life priority order: 1. Wife/kids 2. Family 3. Work (Pays the mortgage and puts food on the table) @Marshalleq The one big criticism I have is comparing this to ZFS plugin, no disrespect, that's like comparing apples to oranges. Until you understand, and my last lengthy post on this thread might give you some insight. Please refrain from complaining. ZFS installs a package at boot, we replace every single file that makes up Unraid other than bzroot-gui. I've said it before, I'll say it again. WE ARE VOLUNTEERS Want enterprise level turnaround times, pay my wages.
  20. 14 points
    This was an interesting one, builds completed and looked fine, but wouldn't boot, which was where the fun began. Initially I thought it was just because we were still using GCC v8 and LT had moved to GCC v9, alas that wasn't the case. After examining all the bits and watching the builds I tried to boot with all the Nvidia files but using a stock bzroot, which worked. So then tried to unpack and repack a stock bzroot, which also reproduced the error. And interestingly the repackaged stock bzroot was about 15mb bigger. Asked LT if anything had changed, as we were still using the same commands as we were when I started this back in ~June 2018. Tom denied anything had changed their end recently. Just told us they were using xz --check=crc32 --x86 --lzma2=preset=9 to pack bzroot with. So changed the packaging to use that for compression, still wouldn't work. At one point I had a repack that worked, but when I tried a build again, I couldn't reproduce it, which induced a lot of head scratching and I assumed my version control of the changes I was making must have been messed up, but damned if I could reproduce a working build, both @bass_rock and me were trying to get something working with no luck. Ended up going down a rabbit hole of analysing bzroot with binwalk, and became fairly confident that the microcode prepended to the bzroot file was good, and it must be the actual packaging of the root filesystem that was the error. We focused in on the two lines relevant the problem being LT had given us the parameter to pack with, but that is receiving an input from cpio so can't be fully presumed to be good, and we still couldn't ascertain that the actual unpack was valid, although it looked to give us a complete root filesystem. Yesterday @bass_rock and I were both running "repack" tests on a stock bzroot to try and get that working, confident that if we could do that the issue would be solved. Him on one side of the pond and me on the other..... changing a parameter at a time and discussing it over Discord. Once again managed to generate a working bzroot file, but tested the same script again and it failed. Got to admit that confused the hell out of me..... Had to go to the shops to pick up some stuff, which gave me a good hour in the car to think about things and I had a thought, I did a lot of initial repacking on my laptop rather than via an ssh connection to an Unraid VM, and I wondered if that may have been the reason I couldn't reproduce the working repack. Reason being, tab completion on my Ubuntu based laptop means I have to prepend any script with ./ whereas on Unraid I can just enter the first two letters of the script name and tab complete will work, obviously I will always take the easiest option. I asked myself if the working build I'd got earlier was failing because it was dependent on being run using ./ and perhaps I'd run it like that on the occasions it had worked. Chatted to bass_rock about it and he kicked off a repackaging of stock bzroot build with --no-absolute-filenames removed from the cpio bit and it worked, we can only assume something must have changed LT side at some point. To put it into context this cpio snippet we've been using since at least 2014/5 or whenever I started with the DVB builds. The scripts to create a Nvidia build are over 800 lines long (not including the scripts we pull in from Slackbuilds) and we had to change 2 of them........ There are 89 core dependencies, which occasionally change with an extra one added or a version update of one of these breaks things. I got a working Nvidia build last night and was testing it for 24 hours then woke up to find FML Slackbuilds have updated the driver since. Have run a build again, and it boots in my VM. Need to test transcoding on bare metal but I can't do that as my daughter is watching a movie, so it'll have to wait until either she goes for a nap or the movie finishes. Just thought I'd give some background for context, please remember all the plugin and docker container authors on here do this in our free time, people like us, Squid, dlandon, bonienl et al put a huge amount of work in, and we do the best we can. Comments like this are not helpful, nor appreciated, so please read the above to find out, and get some insight into why you had to endure the "exhaustion" of constant reminders to upgrade to RC7. Comments like this are welcome and make me happy..... EDT: Tested and working, uploading soon.
  21. 13 points
    Welcome to 6.9 beta release development! This initial -beta1 release is exactly the same code set of 6.8.3 except that the Linux kernel has been updated to 5.5.8 (latest stable as of this date). We have only done basic testing on this release; normally we would not release 'beta' code but some users require the hardware support offered by the latest kernel along with security updates added into 6.8. Important: Beta code is not fully tested and not feature-complete. We recommend running on test servers only! Unfortunately none of our out-of-tree drivers will build with this kernel. Some were reverted back to in-tree version, some were omitted. We anticipate that by the time 6.9 enters 'rc' phase, we'll be on the 5.6 kernel and hopefully some of these out-of-tree drivers will be restored. We will be phasing in some new features, improvements, and changes to address certain bugs over the coming weeks - these will all be -beta releases. Don't be surprised if you see a jump in the beta number, some releases will be private. Version 6.9.0-beta1 2020-03-06 Linux kernel: version 5.5.8 igb: in-tree ixgbe: in-tree r8125: in-tree r750: (removed) rr3740a: (removed) tn40xx: (removed)
  22. 13 points
    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.
  23. 13 points
  24. 12 points
    Nvidia-Driver (only Unraid 6.9.0beta35 and up) This Plugin is only necessary if you are planning to make use of your Nvidia graphics card inside Docker Containers. If you only want to use your Nvidia graphics card for a VM then don't install this Plugin! Discussions about modifications and/or patches that violates the EULA of the driver are not supported by me or anyone here, this could also lead to a take down of the plugin itself! Please remember that this also violates the forum rules and will be removed! Installation of the Nvidia Drivers (this is only necessary for the first installation of the plugin) : Go to the Community Applications App and search for 'Nvidia-Drivers' and click on the Download button (you have to be at least on Unraid 6.9.0beta35 to see the Plugin in the CA App) : Or download it directly from here: https://raw.githubusercontent.com/ich777/unraid-nvidia-driver/master/nvidia-driver.plg After that wait for the plugin to successfully install (don't close the window with the , wait for the 'DONE' button to appear, the installation can take some time depending on your internet connection, the plugin downloads the Nvidia-Driver-Package ~150MB and installs it afterwards to your Unraid server) : Click on 'DONE' and continue with Step 4 (don't close this window for now) : Check if everything is installed correctly and recognized to do this go to the plugin itself if everything shows up PLUGINS -> Nvidia-Driver (if you don't see a driver version at 'Nvidia Driver Version' or another error please scroll down to the Troubleshooting section) : If everything shows up correctly click on the red alert notification from Step 3 (not on the 'X'), this will bring you to the Docker settings. At the Docker page change 'Enable Docker' from 'Yes' to 'No' and hit 'Apply' (you can now close the message from Step 2) : Then again change 'Enable Docker' from 'No' to 'Yes' and hit again 'Apply' (that step is only necessary for the first plugin installation, you can skip that step if you are going to reboot the server - the background to this is that when the Nvidia-Driver-Package is installed also a file is installed that interacts directly with the Docker Daemon itself and the Docker Daemon needs to be reloaded in order to load that file) : After that, you should now be able to utilize your Nvidia graphics card in your Docker containers how to do that see Post 2 in this thread. IMPORTANT: If you don't plan or want to use acceleration within Docker containers through your Nvidia graphics card then don't install this plugin! Please be sure to never use one card for a VM and also in docker containers (your server will hard lock if it's used in a VM and then something want's to use it in a Container). You can use one card for more than one Container at the same time - depending on the capabilities of your card. Troubleshooting: (This section will be updated as soon as more someone reports an issue and will grow over time) NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver. Make sure that the latest NVIDIA driver is installed and running.: This means that the installed driver can't find a supported Nvidia graphics card in your server (it may also be that there is a problem with your hardware - riser cables,...). Check if you accidentally bound all your cards to VFIO, you need at least one card that is supported by the installed driver (you can find a list of all drivers here, click on the corresponding driver at 'Linux x86_64/AMD64/EM64T' and click on the next page on 'Supported products' there you will find all cards that are supported by the driver. If you bound accidentally all cards to VFIO unbind the card you want to use for the Docker container(s) and reboot the server (TOOLS -> System devices -> unselect the card -> BIND SELECTED TO VFIO AT BOOT -> restart your server). docker: Error response from daemon: OCI runtime create failed: container_linux.go:349: starting container process caused "process_linux.go:449: container init caused "process_linux.go:432: running prestart hook 0 caused \"error running hook: exit status 1, stdout: , stderr: nvidia-container-cli: device error: GPU-9cfdd18c-2b41-b158-f67b-720279bc77fd: unknown device\\n\""": unknown.: Please check the 'NVIDIA_VISIBLE_DEVICES' inside your Docker template it may be that you accitentally have what looks like a space at the end or in front of your UUID like: ' GPU-9cfdd18c-2b41-b158-f67b-720279bc77fd' (it's hard to see that in this example but it's there) Reporting Problems: Please be sure if you have a problem to always include a screenshot from the Plugin page, a screenshot of the output of the command 'nvidia-smi' (simply open up a Unraid terminal with the button on the top right of Unraid and type in 'nvidia-smi' without quotes) and the error from the startup of the Container/App if there is any.
  25. 12 points
    This post represents my own personal musings and opinion. This thread (and the broader situation) interests me on a number of levels. We (Royal we) bang on (quite rightly) about our community and how supportive, inclusive, helpful and respectful it is. Values really that any organisation in the world would be lucky for its members to behave consistent with. Saying that, this situation has shown that there is an undercurrent of what I can only call bitterness and to some extent entitlement in some community members. I don’t feel that this is across the board by any means. However, for some, there seems to be a propensity to believe the worst of every (almost like we are waiting to jump on any poorly, Ill-considered or rushed post) word posted by default rather than the positive - which given how together we are supposed to be is very surprising. There could be any number of reasons for this, whether it be the whole keyboard warrior thing, immaturity, mixture of ages of people talking to each other I just don’t know. I think we also have to acknowledge that we are all living in unprecedented times. We are very geographically spread and some are copping it harder than others for sure but we are all in a very in normal place. I have also observed that some (whether that be due to their contribution to this forum or their development work etc.) individuals appear to think that they should be subject to a treatment different to others. I always felt that when doing something in the open source / community space the only reasonable expectation was that there was appreciation from the community for that work and that was enough. It’s volunteer work that plays second fiddle to real life (a fact that many are rightly quick to throw out when the demands of the community get to high). Irrespective of how much those developments have added value to the core product I don’t think those expectations could or should change. Saying that, the community includes the company too and those expectations of appreciation for work done (especially where commercial gain is attained from that work) carries to them too. The thing that surprised me the most though (and again this could be due to the reasons above - or others) is how quick some have been to react negatively (or even just walk) but how slow some have been to react in a more positive way. Perhaps that’s human nature. As I write this I am drawing to a conclusion that we as a community perhaps need to manage our own expectations of what is reasonably expected as a community, developer or company member. This might help (or it might not) help situations like this moving forward.
  26. 12 points
    Note: this community guide is offered in the hope that it is helpful, but comes with no warranty/guarantee/etc. Follow at your own risk. What can you do with WireGuard? Let's walk through each of the connection types: Remote access to server: Use your phone or computer to remotely access your Unraid server, including: Unraid administration via the webgui Access dockers, VMs, and network shares as though you were physically connected to the network Remote access to LAN: Builds on "Remote access to server", allowing you to access your entire LAN as well. Server to server access: Allows two Unraid servers to connect to each other. LAN to LAN access: Builds on "Server to server access", allowing two entire networks to communicate. (see this guide) Server hub & spoke access: Builds on "Remote access to server", except that all of the VPN clients can connect to each other as well. Note that all traffic passes through the server. LAN hub & spoke access: Builds on "Server hub & spoke access", allowing you to access your entire LAN as well. VPN tunneled access: Route traffic for specific Dockers and VMs through a commercial WireGuard VPN provider (see this guide) Remote tunneled access: Securely access the Internet from untrusted networks by routing all of your traffic through the VPN and out Unraid's Internet connection In this guide we will walk through how to setup WireGuard so that your trusted devices can VPN into your home network to access Unraid and the other systems on your network. Prerequisites You must be running Unraid 6.8 with the Dynamix WireGuard plugin from Community Apps Be aware that WireGuard is is technically classified as experimental. It has not gone through a full security audit yet and has not reached 1.0 status. But it is the first open source VPN solution that is extremely simple to install, fast, and designed from the ground up to be secure. Understand that giving someone VPN access to your LAN is just like giving them physical access to your LAN, except they have it 24x7 when you aren't around to supervise. Only give access to people and devices that you trust, and make certain that the configuration details (particularly the private keys) are not passed around insecurely. Regardless of the "connection type" you choose, assume that anyone who gets access to this configuration information will be able to get full access to your network. This guide works great for simple networks. But if you have Dockers with custom IPs or VMs with strict networking requirements, please see the "Complex Networks" section below. Unraid will automatically configure your WireGuard clients to connect to Unraid using your current public IP address, which will work until that IP address changes. To future-proof the setup, you can use Dynamic DNS instead. There are many ways to do this, probably the easiest is described in this 2 minute video from SpaceInvaderOne If your router has UPnP enabled, Unraid will be able to automatically forward the port for you. If not, you will need to know how to configure your router to forward a port. You will need to install WireGuard on a client system. It is available for many operating systems: https://www.wireguard.com/install/ Android or iOS make good first systems, because you can get all the details via QR code. Setting up the Unraid side of the VPN tunnel First, go to Settings -> Network Settings -> Interface eth0. If "Enable bridging" is "Yes", then WireGuard will work as described below. If bridging is disabled, then none of the "Peer type of connections" that involve the local LAN will work properly. As a general rule, bridging should be enabled in Unraid. If UPnP is enabled on your router and you want to use it in Unraid, go to Settings -> Management Access and confirm "Use UPnP" is set to Yes On Unraid 6.8, go to Settings -> VPN Manager Give the VPN Tunnel a name, such as "MyHome VPN" Press "Generate Keypair". This will generate a set of public and private keys for Unraid. Take care not to inadvertently share the private key with anyone (such as in a screenshot like this) By default the local endpoint will be configured with your current public IP address. If you chose to setup DDNS earlier, change the IP address to the DDNS address. Unraid will recommend a port to use. You typically won't need to change this unless you already have WireGuard running elsewhere on your network. Hit Apply If Unraid detects that your router supports UPnP, it will automatically setup port forwarding for you: If you see a note that says "configure your router for port forwarding..." you will need to login to your router and setup the port forward as directed by the note: Some tips for setting up the port forward in your router: Both the external (source) and internal (target/local) ports should be the set to the value Unraid provides. If your router interface asks you to put in a range, use the same port for both the starting and ending values. Be sure to specify that it is a UDP port and not a TCP port. For the internal (target/local) address, use the IP address of your Unraid system shown in the note. Google can help you find instructions for your specific router, i.e. "how to port forward Asus RT-AC68U" Note that after hitting Apply, the public and private keys are removed from view. If you ever need to access them, click the "key" icon on the right hand side. Similarly, you can access other advanced setting by pressing the "down chevron" on the right hand side. They are beyond the scope of this guide, but you can turn on help to see what they do. In the upper right corner of the page, change the Inactive slider to Active to start WireGuard. You can optionally set the tunnel to Autostart when Unraid boots. Defining a Peer (client) Click "Add Peer" Give it a name, such as "MyAndroid" For the initial connection type, choose "Remote access to LAN". This will give your device access to Unraid and other items on your network. Click "Generate Keypair" to generate public and private keys for the client. The private key will be given to the client / peer, but take care not to share it with anyone else (such as in a screenshot like this) For an additional layer of security, click "Generate Key" to generate a preshared key. Again, this should only be shared with this client / peer. Click Apply. Note: Technically, the peer should generate these keys and not give the private key to Unraid. You are welcome to do that, but it is less convenient as the config files Unraid generates will not be complete and you will have to finish configuring the client manually. Configuring a Peer (client) Click the "eye" icon to view the peer configuration. If the button is not clickable, you need to apply or reset your unsaved changes first. If you are setting up a mobile device, choose the "Create from QR code" option in the mobile app and take a picture of the QR code. Give it a name and make the connection. The VPN tunnel starts almost instantaneously, once it is up you can open a browser and connect to Unraid or another system on your network. Be careful not to share screenshots of the QR code with anyone, or they will be able to use it to access your VPN. If you are setting up another type of device, download the file and transfer it to the remote computer via trusted email or dropbox, etc. Then unzip it and load the configuration into the client. Protect this file, anyone who has access to it will be able to access your VPN. About DNS The 2019.10.20 release of the Dynamix Wireguard plugin includes a "Peer DNS Server" option (thanks @bonienl!) If you are having trouble with DNS resolution on the WireGuard client, return to the VPN Manager page in Unraid and switch from Basic to Advanced mode, add the IP address of your desired DNS server into the "Peer DNS Server" field, then install the updated config file on the client. You may want to use the IP address of the router on the LAN you are connecting to, or you could use a globally available IP like 8.8.8.8 This is required for "Remote tunneled access" mode, if the client's original DNS server is no longer accessible after all traffic is routed through the tunnel. If you are using any of the split tunneling modes, adding a DNS server may provide name resolution on the remote network, although you will lose name resolution on the client's local network in the process. The simplest solution is to add a hosts file on the client that provides name resolution for both networks. Complex Networks (updated Feb 20, 2020) The instructions above should work out of the box for simple networks. With "Use NAT" defaulted to Yes, all network traffic on Unraid uses Unraid's IP, and that works fine if you have a simple setup. However, if you have Dockers with custom IPs or VMs with strict networking requirements, things may not work right (I know, kind of vague, but feel free to read the two WireGuard threads for examples) To resolve: In the WireGuard config, set "Use NAT" to No In your router, add a static route that lets your network access the WireGuard "Local tunnel network pool" through the IP address of your Unraid system. For instance, for the default pool of 10.253.0.0/24 you should add this static route: Network: 10.253.0.0/24 (aka 10.253.0.0 with subnet 255.255.255.0) Gateway: <IP address of your Unraid system> On the Docker settings page, set "Host access to custom networks" to "Enabled". see this: https://forums.unraid.net/topic/84229-dynamix-wireguard-vpn/page/8/?tab=comments#comment-808801
  27. 12 points
    Everyone please take a look here: I want to request that any further discussion on this to please take place in that topic.
  28. 12 points
    I know this likely won't matter to anyone but I've been using unraid for just over ten years now and I'm very sad to see how the nvidia driver situation has been handled. While I am very glad that custom builds are no longer needed to add the nvidia driver, I am very disappointed in the apparent lack of communication and appreciation from Limetech to the community members that have provided us with a solution for all the time Limetech would not. If this kind of corporate-esque "we don't care" attitude is going to be adopted then that removes an important differentiating factor between Unraid and Synology, etc. For some of us, cost isn't a barrier. Unraid has an indie appeal with good leaders and a strong community. Please understand how important the unraid community is and appreciate those in the community that put in the time to make unraid better for all of us.
  29. 12 points
    This is a bug fix and security update release. To upgrade: If you are running any 6.4 or later release, click 'Check for Updates' on the Tools/Update OS page. If you are running a pre-6.4 release, click 'Check for Updates' on the Plugins page. If the above doesn't work, navigate to Plugins/Install Plugin, select/copy/paste this plugin URL and click Install: https://s3.amazonaws.com/dnld.lime-technology.com/stable/unRAIDServer.plg Bugs: If you discover a bug or other issue in this release, please open a Stable Releases Bug Report. Overview: Added ability to rebalance a btrfs cache pool to different btrs-raid levels. Support a nifty password strength checker (requires the "Dynamix Password Validator" plugin). Fixed issue where vdisk paths on /mnt/user were not being de-referenced due to qemu change. Added ability to specify whether share file and directory names should be case sensitive or not via SMB. Add docker container VPN network support. Updated kernel, several base packages. Several other small bug fixes. Version 6.8.3 2020-03-05 Changes vs. 6.8.2 Base distro: btrfs-progs: version 5.4.1 cryptsetup: version 2.3.0 mozilla-firefox: version 73.0.1 (CVE-2020-6796, CVE-2020-6797, CVE-2020-6798, CVE-2020-6799, CVE-2020-6800, CVE-2020-6801) libarchive: version 3.4.2 libwebsockets: version 3.2.2 smartmontools: version 7.1 ttyd: version 20200211 wireguard-tools: version 1.0.20200206 (build 2) xfsprogs: version 5.4.0 Linux kernel: version 4.19.108 (CVE-2020-2732) kernel-firmware: version 20200207_6f89735 oot: wireguard: version 0.0.20200215 Management: rc.docker: Allow host access to containers on IPv6 subnets other then /64 rc.inet1: add delay to allow bond initialization smb: add case-sensitiviy config setting per share webgui: removed obsolete 'Notify My Android' notification agent webgui: Docker settings: updated help text webgui: Added "Reboot Now" in banner when OS upgrade is available webgui: dockerMan: Add Security as a category webgui: Docker: added container vpn network support: - allow extra parameters using --net= to overrule default network assignment - add vpn containers are referenced by name in network assignment - add update containers reference when vpn container is updated webgui: Updated: animated spinner logic webgui: Fixed VM settings: allow to stop service when no hardware support webgui: Fixed plugin manager - show correct version for "next" branch webgui: remove 'nl-be' from VM keyboard types webgui: Dont force single threaded VMs for AMD webgui: VMs: enable cpu cache passthrough; AMD + multithreaded webgui: Other miscellaneous updates and css style corrections webgui: Array button renaming webgui: Docker: curl connection time to 15s webgui: Fixed cloning of share attributes webgui: Updated VMs table styling webgui: Updated icon fonts webgui: dockerMan: Add Security as a category webgui: Block referrals to 3rd Party Sites webgui: Fix: /mnt/user path transpose for VM disks webgui: Preserve Reboot Required Notifications across pages webgui: dockerMan: Preserve \n on overview in basic mode webgui: diagnostics: Remove plain-text VNC password webgui: Device Info: added automatic status updating webgui: Added BTRFS balance mode dropdown options webgui: Disallow characters incompatible with FAT32 in share names webgui: Support dropbox/zxcvbn password stregth meter (requires plugin) webgiu: dockerMan: Security enhancements webgui: Notifications: Add switch to not send a browser notification: - Will be utilized by CA to send a notification, but not have the notification appear on the browser but rather as a banner warning Version 6.8.2 2020-01-26 Changes vs. 6.8.1 Base distro: fuse3: version 3.9.0 php: version 7.3.14 (CVE-2020-7060, CVE-2020-7059) rpcbind: version 1.2.5 (rebuilt with --enable-rmtcalls option) ttyd: version 20200120 wireguard-tools: version 1.0.20200121 Linux kernel: version 4.19.98 (CVE-2019-14615) CONFIG_ENIC: Cisco VIC Ethernet NIC Support removed: CONFIG_IGB: Intel(R) 82575/82576 PCI-Express Gigabit Ethernet support removed: CONFIG_IGBVF: Intel(R) 82576 Virtual Function Ethernet support kernel-firmware: version 20200122_1eb2408 oot: Intel igb: version 5.3.5.42 oot: wireguard: version 0.0.20200121 Management: rc.docker: include missing changes to suppoort new setting "Host access to custom networks" rc.nginx: support custom wildcard SSL certs webgui: User password: hide base64 conversion webgui: Select username field when login page is loaded webgui: login: autocapitalize="none" webgui: Passphrase printable charcaters only webgui: Encryption: enforced keyfile selection/deletion when file exists webgui: Use php json_encode to properly encode notifications webgui: Changed Delete keyfile button placement webgui: Detect missing key when keyfile is deleted webgui: Add Network:VPN as an application category webgui: further hardening in auth_request.php webgui: Style adjustment: buttons min-width webgui: login page favicon now matches the green/yellow/red icon from the other webgui pages webgui: VM Manager: add 'virtio-win-0.1.173-2' to VirtIO-ISOs list webgui: Add Network:VPN as an application category webgui: Network settings: updated help text webgui: Fix link for Password Recovery on login screen Version 6.8.1 2020-01-10 Changes vs. 6.8.0 Base distro: libuv: version 1.34.0 libvirt: version 5.10.0 mozilla-firefox: version 72.0.1 (CVE-2019-17026, CVE-2019-17015, CVE-2019-17016, CVE-2019-17017, CVE-2019-17018, CVE-2019-17019, CVE-2019-17020, CVE-2019-17021, CVE-2019-17022, CVE-2019-17023, CVE-2019-17024, CVE-2019-17025) php: version 7.3.13 (CVE-2019-11044 CVE-2019-11045 CVE-2019-11046 CVE-2019-11047 CVE-2019-11049 CVE-2019-11050) qemu: version 4.2.0 samba: version 4.11.4 ttyd: version 20200102 wireguard-tools: version 1.0.20200102 Linux kernel: version 4.19.94 kernel_firmware: version 20191218_c4586ff (with additional Intel BT firmware) CONFIG_THUNDERBOLT: Thunderbolt support CONFIG_INTEL_WMI_THUNDERBOLT: Intel WMI thunderbolt force power driver CONFIG_THUNDERBOLT_NET: Networking over Thunderbolt cable oot: Highpoint rr3740a: version v1.19.0_19_04_04 oot: Highpoint r750: version v1.2.11-18_06_26 [restored] oot: wireguard: version 0.0.20200105 Management: add cache-busting params for noVNC url assets emhttpd: fix cryptsetup passphrase input network: disable IPv6 for an interface when its settings is "IPv4 only". webgui: Management page: fixed typos in help text webgui: VM settings: fixed Apply button sometimes not working webgui: Dashboard: display CPU load full width when no HT webgui: Docker: show 'up-to-date' when status is unknown webgui: Fixed: handle race condition when updating share access rights in Edit User webgui: Docker: allow to set container port for custom bridge networks webgui: Better support for custom themes (not perfect yet) webgui: Dashboard: adjusted table positioning webgui: Add user name and user description verification webgui: Edit User: fix share access assignments webgui: Management page: remove UPnP conditional setting webgui: Escape shell arg when logging csrf mismatch webgui: Terminal button: give unsupported warning when Edge/MSIE is used webgui: Patched vulnerability in auth_request webgui: Docker: added new setting "Host access to custom networks" webgui: Patched vulnerability in template.php
  30. 12 points
    Hi everyone: I am Squids wife. I just wanted everyone to know he will be 50 on Sunday March 22nd, If you all can wish him a happy birthday that would be great.Due to Covid 19 - no party. Thanks Tracey
  31. 12 points
    Back in the saddle ... Sorry for the long delay in publishing this release. Aside from including some delicate coding, this release was delayed due to several team members, chiefly myself, having to deal with various non-work-related challenges which greatly slowed the pace of development. That said, there is quite a bit in this release, LimeTech is growing and we have many exciting features in the pipe - more on that in the weeks to come. Thanks to everyone for their help and patience during this time. Cheers, -Tom IMPORTANT: This is Beta software. We recommend running on test servers only! KNOWN ISSUE: with this release we have moved to the latest Linux 5.8 stable kernel. However, we have discovered that a regression has been introduced in the mtp3sas driver used by many LSI chipsets, e.g., LSI 9201-16e. Typically looks like this on System Devices page: Serial Attached SCSI controller: Broadcom / LSI SAS2116 PCI-Express Fusion-MPT SAS-2 [Meteor] (rev 02) The problem is that devices are no longer recognized. There are already bug reports pertaining to this issue: https://bugzilla.kernel.org/show_bug.cgi?id=209177 https://bugzilla.redhat.com/show_bug.cgi?id=1878332 We have reached out to the maintainer to see if a fix can be expedited, however we feel that we can neither revert back to 5.7 kernel nor hold the release due to this issue. We are monitoring and will publish a release with fix asap. ANOTHER known issue: we have added additional btrfs balance options: raid1c3 raid1c4 and modified the raid6 balance operation to set meta-data to raid1c3 (previously was raid1). However, we have noticed that applying one of these balance filters to a completely empty volume leaves some data extents with the previous profile. The solution is to simply run the same balance again. We consider this to be a btrfs bug and if no solution is forthcoming we'll add the second balance to the code by default. For now, it's left as-is. THE PRIMARY FOCUS of this release is to put tools in place to help users migrate data off SSD-based pools so that those devices may be re-partitioned if necessary, and then migrate the data back. What are we talking about? For several years now, storage devices managed by Unraid OS are formatted with an "Unraid Standard Partition Layout". This layout has partition 1 starting at offset 32KiB from the start of the device, and extending to the end of the device. (For devices with 512-byte sectors, partition 1 starts in sector 64; for 4096-byte sector size devices, partition 1 starts in sector 8.) This layout achieves maximum storage efficiency and ensures partition 1 starts on a 4096-byte boundary. Through user reports and extensive testing however, we have noted that many modern SSD devices, in particular Samsung EVO, do not perform most efficiently using this partition layout, and the devices seem to write far more than one would expect, and with SSD, one wants to minimize writes to SSD as much as possible. The solution to the "excessive SSD write" issue is to position partition 1 at offset 1MiB from the start of the device instead of at 32KiB. The will both increase performance and decrease writes with affected devices. Do you absolutely need to re-partition your SSD's? Probably not depending on what devices you have. Click on a device from Main, scroll down to Attributes and take a look at Data units written. If this is increasing very rapidly then you probably would benefit by re-partitioning. Note: if you have already (re)Formatted using previous 6.9-beta release, for SSD smaller than 2TiB the proper partition layout will appear like this on the Device Information page: Partition format: MBR: 1MiB-aligned For SSD larger than 2TiB: Partition format: GPT: 1MiB-aligned Here's what's in this release to help facilitate re-partitioning of SSD devices: An Erase button which appears in the Device Information page. The Erase button may be used to erase (delete) content from a volume. A volume is either the content of an unRAID array data disk, or the content of a pool. In the case of an unRAID disk, only that device is erased; in the case of a multiple-device pool ALL devices of the pool are erased. The extent of Erase varies depending on whether the array is Stopped, or Started in Maintenance mode (if started in Normal mode, all volume Erase buttons are disabled). Started/Maintenance mode: in this case the LUKS header (if any) and any file system within partition 1 is erased. The MBR (master boot record) is not erased. Stopped - in this case, unRAID array disk volumes and pool volumes are treated a little differently: unRAID array disk volumes - if Parity and/or Parity2 is valid, then operation proceeds exactly as above, that is, content of only partition 1 is erased but the MBR (master boot record) is left as-is; but, if there is no valid parity, then the MBR is also erased. Pool volumes - partition 1 of all devices within the pool are erased, and then the MBR is also erased. The purpose of erasing the MBR is to permit re-partitioning of the device if required. Upon format, Unraid OS will position partition 1 at 32KiB for HDD devices and at 1MiB for SSD devices. Note that erase does not overwrite the storage content of a device, it simply clears the LUKS header if present (which effectively makes the device unreadable), and file system and MBR signatures. A future Unraid OS release may include the option of overwriting the data. Additional "Mover" capabilities. Since SSD pools are commonly used to store vdisk images, shfs/mover is now aware of: sparse files - when a sparse file is moved from one volume to another, it's sparseness is preserved NoCOW attribute - when a file or directory in a btrfs volume has the NoCOW attribute set, the attribute is preserved when the file or directory is moved to another btrfs volume. Note that btrfs subvolumes are not preserved. A future Unraid OS release may include preservation of btrfs subvolumes. Ok how do I re-partition my SSD pools? Outlined here are two basic methods: "Mover" method - The idea is to use the Mover to copy all data from the pool to a target device in the unRAID array. Then erase all devices of the pool, and reformat. Finally use the Mover to copy all the data back. "Unassign/Re-assign" method - The idea here is, one-by-one, remove a device from a btrfs pool, balance the pool with reduced device count, then re-assign the device back to the pool, and balance pool back to include the device. This works because Unraid OS will re-partition new devices added to an existing btrfs pool. This method is not recommended for a pool with more than 2 devices since the first balance operation may be write-intensive, and writes are what we're trying to minimize. Also it can be tricky to determine if enough free space really exists after removing a device to rebalance the pool. Finally, this method will introduce a time window where your data is on non-redundant storage. No matter which method, if you have absolutely critical data in the pool we strongly recommend making an independent backup first (you are already doing this right?). Mover Method This procedure presumes a multi-device btrfs pool containing one or more cache-only or cache-prefer shares. 1. With array Started, stop any VM's and/or Docker applications which may be accessing the pool you wish to re-partition. Make sure no other external I/O is targeting this pool. 2. For each share on the pool, go to the Share Settings page and make some adjustments: change from cache-only (or cache-prefer) to cache-yes assign an array disk or disks via Include mask to receive the data. If you wish to preserve the NoCOW attribute (Copy-on-write set to No) on files and directories, these disks should be formatted with btrfs. Of course ensure there is enough free space to receive the data. 3. Now go back to Main and click the Move button. This will move the data of each share to the target array disk(s). 4. Verify no data left on the pool, Stop array, click on the pool and then click the Erase button. 5. Start the array and the pool should appear Unformatted - go ahead and Format the pool (this is what will re-write the partition layout). 6. Back to Share Settings page; for each above share: change from cache-yes to cache-prefer 7. On Main page click Move button. This will move data of each share back to the pool. 8. Finally, back to Share Settings page; for each share: change from cache-prefer back to cache-only if desired Unassign/Re-assign Method Stop array and unassign one of the devices from your existing pool; leave device unassigned. Start array. A balance will take place on your existing pool. Let the balance complete. Stop array. Re-assign the device, adding it back to your existing pool. Start array. The added device will get re-partitioned and a balance will start moving data to the new device. Let the balance complete. Repeat steps 1-4 for the other device in your existing pool. Whats happening here is this: At the completion of step 2, btrfs will 'delete' the missing device from the volume and wipe the btrfs signature from it. At the beginning of step 4, Unraid OS will re-partition the new device being added to an existing pool. I don't care about preserving data in the pool. In this case just Stop array, click on the pool and then click Erase. Start array and Format the pool - done. Useful to know: when Linux creates a file system in an SSD device, it will first perform a "blkdiscard" on the entire partition. Similarly, "blkdisard" is initiated on partition 1 on a new device added to an existing btrfs pool. What about array devices? If you have SSD devices in the unRAID array the only way to safely re-partition those devices is to either remove them from the array, or remove parity devices from the array. This is because re-partitioning will invalidate parity. Note also the volume size will be slightly smaller. Version 6.9.0-beta29 2020-09-27 (vs -beta25) Base distro: at-spi2-core: version 2.36.1 bash: version 5.0.018 bridge-utils: version 1.7 brotli: version 1.0.9 btrfs-progs: version 5.6.1 ca-certificates: version 20200630 cifs-utils: version 6.11 cryptsetup: version 2.3.4 curl: version 7.72.0 (CVE-2020-8231) dbus: version 1.12.20 dnsmasq: version 2.82 docker: version 19.03.13 ethtool: version 5.8 fribidi: version 1.0.10 fuse3: version 3.9.3 git: version 2.28.0 glib2: version 2.66.0 build 2 gnutls: version 3.6.15 gtk+3: version 3.24.23 harfbuzz: version 2.7.2 haveged: version 1.9.13 htop: version 3.0.2 iproute2: version 5.8.0 iputils: version 20200821 jasper: version 2.0.21 jemalloc: version 5.2.1 libX11: version 1.6.12 libcap-ng: version 0.8 libevdev: version 1.9.1 libevent: version 2.1.12 libgcrypt: version 1.8.6 libglvnd: version 1.3.2 libgpg-error: version 1.39 libgudev: version 234 libidn: version 1.36 libpsl: version 0.21.1 build 2 librsvg: version 2.50.0 libssh: version 0.9.5 libvirt: version 6.6.0 (CVE-2020-14339) libxkbcommon: version 1.0.1 libzip: version 1.7.3 lmdb: version 0.9.26 logrotate: version 3.17.0 lvm2: version 2.03.10 mc: version 4.8.25 mpfr: version 4.1.0 nano: version 5.2 ncurses: version 6.2_20200801 nginx: version 1.19.1 ntp: version 4.2.8p15 build 2 openssl-solibs: version 1.1.1h openssl: version 1.1.1h p11-kit: version 0.23.21 pango: version 1.46.2 php: version 7.4.10 (CVE-2020-7068) qemu: version 5.1.0 (CVE-2020-10717, CVE-2020-10761) rsync: version 3.2.3 samba: version 4.12.7 (CVE-2020-1472) sqlite: version 3.33.0 sudo: version 1.9.3 sysvinit-scripts: version 2.1 build 35 sysvinit: version 2.97 ttyd: version 1.6.1 util-linux: version 2.36 wireguard-tools: version 1.0.20200827 xev: version 1.2.4 xf86-video-vesa: version 2.5.0 xfsprogs: version 5.8.0 xorg-server: version 1.20.9 build 3 xterm: version 360 xxHash: version 0.8.0 Linux kernel: version 5.8.12 kernel-firmware: version kernel-firmware-20200921_49c4ff5 oot: Realtek r8152: version 2.13.0 oot: Tehuti tn40xx: version 0.3.6.17.3 Management: btrfs: include 'discard=async' mount option emhttpd: avoid using remount to set additional mount options emhttpd: added wipefs function (webgui 'Erase' button) shfs: move: support spares files shfs: move: preserve ioctl_iflags when moving between same file system types smb: remove setting 'aio' options in smb.conf, use samba defaults webgui: Update noVNC to v1.2.0 webgui: Docker: more intuitive handling of images webgui: VMs: more intuitive handling of image selection webgui: VMs: Fixed: rare cases vdisk defaults to Auto when it should be Manual webgui: VMs: Fixed: Adding NICs or VirtFS mounts to a VM is limited webgui: VM manager: new setting "Network Model" webgui: Added new setting "Enable user share assignment" to cache pool webgui: Dashboard: style adjustment for server icon webgui: Update jGrowl to version 1.4.7 webgui: Fix ' appearing webgui: VM Manager: add 'virtio-win-0.1.189-1' to VirtIO-ISOs list webgui: Prevent bonded nics from being bound to vfio-pci too webgui: better handling of multiple nics with vfio-pci webgui: Suppress WG on Dashboard if no tunnels defined webgui: Suppress Autofan link on Dashboard if plugin not installed webgui: Detect invalid session and logout current tab webgui: Added support for private docker registries with basic auth or no auth, and improvements for token based authentication webgui: Fix notifications continually reappearing webgui: Support links on notifications webgui: Add raid1c3 and raid1c4 btrfs pool balance options. webgui: For raid6 btrfs pool data profile use raid1c3 metadata profile. webgui: Permit file system configuration when array Started for Unmountable volumes. webgui: Fix not able to change parity check schedule if no cache pool present webgui: Disallow "?" in share names webgui: Add customizable timeout when stopping containers
  32. 12 points
    Here is a video guide for setting up Jitsi
  33. 11 points
    So there is actually a credits page in the Unraid webGui, but right now we only list the people who've directly contributed to code that lives inside the OS itself, not plugins, containers, or other 3rd party modifications. But having a place on either the website or another spot that can showcase our community and the developers that participate here isn't a bad idea!
  34. 11 points
    As a user of Unraid I am very scared about the current trends. Unraid as a base it is a very good server operating system but what makes it special are the community applications. I would be very sad if this breaks apart because of maybe wrong or misunderstandable communication. I hope that everyone will get together again. For us users you would make us all a pleasure. I have 33 docker containers and 8 VM running on my system and I hope that my system will continue to be as usable as before. I have many containers from linuxserver.io. I am grateful for the support from limetech & the whole community and hope it will be continued. sorry for my english i hope you could understand me.
  35. 11 points
    @trurl Please lock this thread. Due to an unexpected announcement from @limetech this is no longer required. I'm quitting Unraid work.
  36. 11 points
    SSD support in Linux and associated file systems has been in place quite a while and is quite mature at this point. However don't be so quick to discount advances in spinners - that industry is not going away quietly and probably will be several years before we see the last of them. With 6.9 we have introduced "multiple pools". At present this only supports btrfs pools but much of the underlying work has been done to support other types of pools (that is, formatted with a file system other than btrfs). Along with this, it gives us a path to generalize pools further and let you define multiple "unRAID" pools. This work will require changes in the unRAID kernel driver, and is naturally the time to address SSD devices in the unRAID array, as well as a few other improvements. How this work is phased into future releases is T.B.D.
  37. 11 points
    Yes we are preparing a 6.9 beta release with 5.5.8 kernel, and then move to 5.6 kernel ultimately.
  38. 10 points
    You know you could have discussed this with me right? Remember me, the original dev, along with @bass_rock! The one you tasked @jonp to discuss how we achieved the Nvidia builds back in December last year? That I never heard anything more about. I'm the one that spend 6 months f**king around with Unraid to get the GPU drivers working in docker containers. The one that's been hosting literally 100s of custom Unraid builds for the community to use for nearly five years. With all due respect to @ich777 he wasn't the one who did the bulk of the work here. Remember? You'll be pleased to know I will no longer be producing any custom "unofficial" builds for all the things you've not wanted to pick up and support for the last 10 years. A bit like unassigned devices and @dlandon, hell that should have been incorporated half a decade ago. In fact, I won't be doing anything here from this point on. Nearly 5 years of DVB and nearly 2 years of Nvidia. You're welcome to them. DVB is all yours now as well. Good Luck.
  39. 10 points
    Changes vs. 6.9.0-beta29 include: Added workaround for mpt3sas not recognizing devices with certain LSI chipsets. We created this file: /etc/modprobe.d/mpt3sas-workaround.conf which contains this line: options mpt3sas max_queue_depth=10000 When the mpt3sas module is loaded at boot, that option will be specified. If you add "mpt3sas.max_queue_depth=10000" to syslinux kernel append line, you can remove it. Likewise, if you manually load the module via 'go' file, can also remove it. When/if the mpt3sas maintainer fixes the core issue in the driver we'll get rid of this workaround. Reverted libvirt to v6.5.0 in order to restore storage device passthrough to VM's. A handful of other bug fixes, including 'unblacklisting' the ast driver (Aspeed GPU driver). For those using that on-board graphics chips, primarily Supermicro, this should increase speed and resolution of local console webGUI. Version 6.9.0-beta30 2020-10-05 (vs -beta29) Base distro: libvirt: version 6.5.0 [revert from version 6.6.0] php: version 7.4.11 (CVE-2020-7070, CVE-2020-7069) Linux kernel: version 5.8.13 ast: removed blacklisting from /etc/modprobe.d mpt3sas: added /etc/modprobe.d/mpt3sas-workaround.conf to set "max_queue_depth=10000" Management: at: suppress session open/close syslog messages emhttpd: correct 'Erase' logic for unRAID array devices emhtppd: wipefs encrypted device removed from multi-device pool emhttpd: yet another btrfs 'free/used' calculation method webGUI: Update statuscheck webGUI: Fix dockerupdate.php warnings
  40. 10 points
    I agree that it's not okay to complain about not hearing anything since B1. If for no other reason than this is a crazy time (I've thought a few times "man, I hope those guys aren't sick"). But I would say that it's a missed opportunity to not share at least something of what's happening behind the scenes. This is a pretty committed and passionate user-base, and some level of sharing would only strengthen it. I work in big-tech myself, so I get the struggle of figuring out how much to share with your customers. A monthly blog with some latest development details, near-term roadmap info, things to look forward to with unraid, etc, would go a long way IMHO.
  41. 10 points
    Just caught onto this today (Thx @SpaceInvaderOne !), saw we're "only" #2, which just won't do --- Just "remembered" I have a Threadripper 2950x new in box - was going to sell the old dual Xeon E5 V2s and upgrade, but now going to bring this out & join the fray with the I9-9900 Hackintosh [AMD 580] and Ryzen 3700x. The threadripper will have to go "benchtop bare" for now, but that's OK. Should probably just use the office for a sauna now 🥵. Think the UPS is sweating a tad.... I am regional medical director for a company that does home medical visits on the sickest of the (US Medicare) population, IE top tier risk for COVID, avg. patient age 80+. We have offices in all the top affected cities in US so far. We're working nonstop to try to keep our patients safe at home. We've had to retreat temporarily to mostly telephonic visits due to shortage of PPE (protective gear) til our supply improves so we don't spread it to them - very frustrating. Now I can feel better about being stuck at home, still helping on the compute side as well til we get to get back safely in their homes. I wanted to thank everyone here for being so eager to take part / take action and with such impressive results. It means alot in the medical world to see folks being resourceful and doing their part. Please stay home, stay safe, and round up some more CPU's for this !
  42. 10 points
  43. 10 points
    Due to a security vulnerability discovered in forms-based authentication: ALL USERS ARE STRONGLY ENCOURAGED TO UPGRADE To upgrade: If you are running any 6.4 or later release, click 'Check for Updates' on the Tools/Update OS page. If you are running a pre-6.4 release, click 'Check for Updates' on the Plugins page. If the above doesn't work, navigate to Plugins/Install Plugin, select/copy/paste this plugin URL and click Install: https://s3.amazonaws.com/dnld.lime-technology.com/stable/unRAIDServer.plg Refer also to @ljm42 excellent 6.4 Update Notes which are helpful especially if you are upgrading from a pre-6.4 release. Bugs: If you discover a bug or other issue in this release, please open a Stable Releases Bug Report. Overfiew This is a bug fix and security update release. Some users are reporting problems booting due to a crash in the in-tree Intel IGB ethernet driver. We replaced the in-tree driver with latest out-of-tree driver. We fixed a longstanding issue where LibreELEC/Kodi could not browse NFS shares. The fix was to rebuild the rpcbind program, including a new option: --enable-rmtcalls Version 6.8.1 included a new docker option "Host access to custom networks" (thanks @bonienl) but I left out a critical change in the rc.docker script, sorry about that, now fixed. Fixed an encryption issue: if you first tried 'keyfile' method to specify encryption key, and that fails, any attempt to enter a passphrase would also fail, since a keyfile still exists, emhttpd used that as encryption key. This is fixed in webGUI by detecting presence of an encryption keyfile and offering only to re-download a new keyfile or delete the current one. Once deleted, you can then enter a passphrase. Small change to properly support custom SSL wildcard certs (thanks @ljm42) Updated kernel, wireguard, other base packages Numerous webGUI fixes and refinements (thanks @bonienl, @Squid, @gfjardim) A note regarding encryption passphrases: There is a warning in the Help text for passphrase which reads: Prior to this release (6.8.2) we did not enforce this restriction, but now we are. Unfortunately this means for those who have previously used a passphrase including other characters, you will need to use the "keyfile" method. We will add a feature in a future release that will let you change your passphrase/keyfile. Version 6.8.2 2020-01-26 Changes vs. 6.8.1 Base distro: fuse3: version 3.9.0 php: version 7.3.14 (CVE-2020-7060, CVE-2020-7059) rpcbind: version 1.2.5 (rebuilt with --enable-rmtcalls option) ttyd: version 20200120 wireguard-tools: version 1.0.20200121 Linux kernel: version 4.19.98 (CVE-2019-14615) CONFIG_ENIC: Cisco VIC Ethernet NIC Support removed: CONFIG_IGB: Intel(R) 82575/82576 PCI-Express Gigabit Ethernet support removed: CONFIG_IGBVF: Intel(R) 82576 Virtual Function Ethernet support kernel-firmware: version 20200122_1eb2408 oot: Intel igb: version 5.3.5.42 oot: wireguard: version 0.0.20200121 Management: rc.docker: include missing changes to suppoort new setting "Host access to custom networks" rc.nginx: support custom wildcard SSL certs webgui: User password: hide base64 conversion webgui: Select username field when login page is loaded webgui: login: autocapitalize="none" webgui: Passphrase printable charcaters only webgui: Encryption: enforced keyfile selection/deletion when file exists webgui: Use php json_encode to properly encode notifications webgui: Changed Delete keyfile button placement webgui: Detect missing key when keyfile is deleted webgui: Add Network:VPN as an application category webgui: further hardening in auth_request.php webgui: Style adjustment: buttons min-width webgui: login page favicon now matches the green/yellow/red icon from the other webgui pages webgui: VM Manager: add 'virtio-win-0.1.173-2' to VirtIO-ISOs list webgui: Add Network:VPN as an application category webgui: Network settings: updated help text webgui: Fix link for Password Recovery on login screen Version 6.8.1 2020-01-10 Changes vs. 6.8.0 Base distro: libuv: version 1.34.0 libvirt: version 5.10.0 mozilla-firefox: version 72.0.1 (CVE-2019-17026, CVE-2019-17015, CVE-2019-17016, CVE-2019-17017, CVE-2019-17018, CVE-2019-17019, CVE-2019-17020, CVE-2019-17021, CVE-2019-17022, CVE-2019-17023, CVE-2019-17024, CVE-2019-17025) php: version 7.3.13 (CVE-2019-11044 CVE-2019-11045 CVE-2019-11046 CVE-2019-11047 CVE-2019-11049 CVE-2019-11050) qemu: version 4.2.0 samba: version 4.11.4 ttyd: version 20200102 wireguard-tools: version 1.0.20200102 Linux kernel: version 4.19.94 kernel_firmware: version 20191218_c4586ff (with additional Intel BT firmware) CONFIG_THUNDERBOLT: Thunderbolt support CONFIG_INTEL_WMI_THUNDERBOLT: Intel WMI thunderbolt force power driver CONFIG_THUNDERBOLT_NET: Networking over Thunderbolt cable oot: Highpoint rr3740a: version v1.19.0_19_04_04 oot: Highpoint r750: version v1.2.11-18_06_26 [restored] oot: wireguard: version 0.0.20200105 Management: add cache-busting params for noVNC url assets emhttpd: fix cryptsetup passphrase input network: disable IPv6 for an interface when its settings is "IPv4 only". webgui: Management page: fixed typos in help text webgui: VM settings: fixed Apply button sometimes not working webgui: Dashboard: display CPU load full width when no HT webgui: Docker: show 'up-to-date' when status is unknown webgui: Fixed: handle race condition when updating share access rights in Edit User webgui: Docker: allow to set container port for custom bridge networks webgui: Better support for custom themes (not perfect yet) webgui: Dashboard: adjusted table positioning webgui: Add user name and user description verification webgui: Edit User: fix share access assignments webgui: Management page: remove UPnP conditional setting webgui: Escape shell arg when logging csrf mismatch webgui: Terminal button: give unsupported warning when Edge/MSIE is used webgui: Patched vulnerability in auth_request webgui: Docker: added new setting "Host access to custom networks" webgui: Patched vulnerability in template.php
  44. 9 points
    This thread will serve as the support thread for the GPU statistics plugin (gpustat). Currently, a single nVidia card is supported. No testing outside this scenario has been done and is not guaranteed to work in any fashion. UPDATE: 2020-04-18 Released - Allow user-selectable display of metrics on plugin widget Prerequisite: 6.7.1+ Unraid-Nvidia plugin with nVidia build installed. Plugin is now live on CA but if you want to manually install see the below -- To review the source before installing (**You should always do this**): https://github.com/b3rs3rk/gpustat-unraid Manual Plugin Installation URL: https://raw.githubusercontent.com/b3rs3rk/gpustat-unraid/master/gpustat.plg Enjoy! ====================================================================== Information to Include when asking for Support: 1) the result of 'nvidia-smi -q -x -i 0' from the UnRAID console (via SSH or the webterminal is fine) 2) the result of 'cd /usr/local/emhttp/plugins/gpustat/ && php ./gpustatus.php' 3) a screenshot of the dashboard plugin (if issue is only seen during transcoding, then a snippet during transcode is best)
  45. 9 points
    I'm using Unraid for a while now and collected some experience to boost the SMB transfer speeds: 1.) Choose the right CPU The most important part is to understand that SMB is single-threaded. This means SMB uses only one CPU core to transfer a file. This is valid for the server and the client. Usually this is not a problem as SMB does not fully utilize a CPU core (except of real low powered CPUs). But Unraid adds, because of the ability to split shares across multiple disks, an additional process called SHFS and its load raises proportional to the transfer speed, which could overload your CPU core. So the most important part is, to choose the right CPU. At the moment I'm using an i3-8100 which has 4 cores and 2257 single thread passmark points: And since I have this single thread power I'm able to use the full bandwith of my 10G network adapter which was not possible with my previous Intel Atom C3758 (857 points) although both have comparable total performance. I even was not able to reach 1G speeds while a parallel Windows Backup was running (see next section to bypass this limitation). Now I'm able to transfer thousands of small files and parallely transfer a huge file with 250 MB/s. With this experience I suggest a CPU that has around 1400 single thread passmark points to fully utilize a 1G ethernet port. As an example: The smallest CPU I would suggest for Unraid is an Intel Pentium Silver J5040. P.S. Passmark has a list sorted by single thread performance for desktop CPUs and server CPUs. 2.) Bypass single-thread limitation The single-thread limitation of SMB and SHFS can be bypassed through opening multiple connections to your server. This means connecting to "different" servers. The easiest way to accomplish that, is to use the ip-address of your server as a "second" server while using the same user login: \\tower\sharename -> best option for user access through file explorer as it is automatically displayed \\10.0.0.2\sharename -> best option for backup softwares, you could map it as a network drive If you need more connections, you can add multiple entries to your windows hosts file (Win+R and execute "notepad c:\windows\system32\drivers\etc\hosts"): 10.0.0.2 tower2 10.0.0.2 tower3 Results If you now download a file from your Unraid server through \\10.0.0.2 while a backup is running on \\tower, it will reach the maximum speed while a download from \\tower is massively throttled: 3.) Bypass Unraid's SHFS process If you enable access directly to the cache disk and upload a file to //tower/cache, this will bypass the SHFS process. Beware: Do not move/copy files between the cache disk and shares as this could cause data loss! The eligible user account will be able to see all cached files, even those from other users. Temporary Solution or "For Admins only" As Admin or for a short test you could enable "disk shares" under Settings -> Global Share Settings: By that all users can access all array and cache disks as SMB shares. As you don't want that, your first step is to click on each Disk in the WebGUI > Shares and forbid user access, except for the cache disk, which gets read/write access only for your "admin" account. Beware: Do not create folders in the root of the cache disk as this will create new SMB Shares Safer Permanent Solution Use this explanation. Results In this thread you can see the huge difference between copying to a cached share or copying directly to the cache disk. 4.) Enable SMB Multichannel + RSS SMB Multichannel is a feature of SMB3 that allows splitting file transfers across multiple NICs (Multichannel) and multiple CPU Cores (RSS) since Windows 8. This will raise your throughput depending on your amount of NICs, NIC bandwidth, CPU and used settings: This feature is experimental SMB Multichannel is considered experimental since its release with Samba 4.4. The main bug for this state is resolved in Samba 4.13. The Samba developers plan to resolve all bugs with 4.14. Unraid 6.8.3 contains Samba 4.11. This means you use Multichannel on your own risk! Multichannel for Multiple NICs Lets say your mainboard has four 1G NICs and your Client has a 2.5G NIC. Without Multichannel the transfer speed is limited to 1G (117,5 MByte/s). But if you enable Multichannel it will split the file transfer across the four 1G NICs boosting your transfer speed to 2.5G (294 MByte/s): Additionally it uses multiple CPU Cores which is useful to avoid overloading smaller CPUs. To enable Multichannel you need to open the Unraid Webterminal and enter the following (the file is usually empty, so do not wonder): nano /boot/config/smb-extra.conf And add the following to it: server multi channel support = yes Press "Enter+X" and confirm with "Y" and "Enter" to save the file. Then restart the Samba service with this command: samba restart Eventually you need to reboot your Windows Client, but finally its enabled and should work. Multichannel + RSS for Single and Multiple NICs But what happens if you're server has only one NIC. Now Multichannel is not able to split something, but it has a sub-feature called RSS which is able to split file transfers across multiple CPU cores with a single NIC: Of course this feature works with multiple NICs: And this is important, because it creates multiple single-threaded SMB processes and SHFS processes which are now load balanced across all CPU cores, instead of overloading only a single core. So if your server has slow SMB file transfers while your overall CPU load in the Unraid WebGUI Dashboard is not really high, enabling RSS will boost your SMB file transfer to the maximum! But it requires RSS capability on both sides. You need to check your servers NIC by opening the Unraid Webterminal and entering this command (could be obsolete with Samba 4.13 as they built-in an RSS autodetection ) egrep 'CPU|eth*' /proc/interrupts It must return multiple lines (each for one CPU core) like this: egrep 'CPU|eth0' /proc/interrupts CPU0 CPU1 CPU2 CPU3 129: 29144060 0 0 0 IR-PCI-MSI 524288-edge eth0 131: 0 25511547 0 0 IR-PCI-MSI 524289-edge eth0 132: 0 0 40776464 0 IR-PCI-MSI 524290-edge eth0 134: 0 0 0 17121614 IR-PCI-MSI 524291-edge eth0 Now you can check your Windows 8 / Windows 10 client by opening Powershell as Admin and enter this command: Get-SmbClientNetworkInterface It must return "True" for "RSS Capable": Interface Index RSS Capable RDMA Capable Speed IpAddresses Friendly Name --------------- ----------- ------------ ----- ----------- ------------- 11 True False 10 Gbps {10.0.0.10} Ethernet 3 Now, after you are sure that RSS is supported on your server, you can enable Multichannel + RSS by opening the Unraid Webterminal and enter the following (the file is usually empty, so do not wonder): nano /boot/config/smb-extra.conf Add the following and change 10.10.10.10 to your Unraid servers IP and speed to "10000000000" for 10G adapter or to "1000000000" for a 1G adapter: server multi channel support = yes interfaces = "10.10.10.10;capability=RSS,speed=10000000000" If you are using multiple NICs the syntax looks like this (add RSS capability only for supporting NICs!): interfaces = "10.10.10.10;capability=RSS,speed=10000000000" "10.10.10.11;capability=RSS,speed=10000000000" Press "Enter+X" and confirm with "Y" and "Enter" to save the file. Now restart the SMB service: samba restart Does it work? After rebooting your Windows Client (seems to be a must), download a file from your server (so connection is established) and now you can check if Multichannel + RSS works by opening Windows Powershell as Admin and enter this command: Get-SmbMultichannelConnection -IncludeNotSelected It must return a line similar to this (a returned line = Multichannel works) and if you want to benefit from RSS then "Client RSS Cabable" must be "True": Server Name Selected Client IP Server IP Client Interface Index Server Interface Index Client RSS Capable Client RDMA Capable ----------- -------- --------- --------- ---------------------- ---------------------- ------------------ ------------------- tower True 10.10.10.100 10.10.10.10 11 13 True False If you are interested in test results, look here. 5.) smb.conf Settings Tuning At the moment I'm doing intense tests with different SMB config settings found on different websites: https://wiki.samba.org/index.php/Performance_Tuning https://wiki.samba.org/index.php/Linux_Performance https://wiki.samba.org/index.php/Server-Side_Copy https://www.samba.org/~ab/output/htmldocs/Samba3-HOWTO/speed.html https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html https://lists.samba.org/archive/samba-technical/attachments/20140519/642160aa/attachment.pdf https://www.samba.org/samba/docs/Samba-HOWTO-Collection.pdf https://www.samba.org/samba/docs/current/man-html/ (search for "vfs") https://lists.samba.org/archive/samba/2016-September/202697.html https://codeinsecurity.wordpress.com/2020/05/18/setting-up-smb-multi-channel-between-freenas-or-any-bsd-linux-and-windows-for-20gbps-transfers/ https://www.snia.org/sites/default/files/SDC/2019/presentations/SMB/Metzmacher_Stefan_Samba_Async_VFS_Future.pdf https://www.heise.de/newsticker/meldung/Samba-4-12-beschleunigt-Verschluesselung-und-Datentransfer-4677717.html I will post my results after all tests have been finished. By now I would say it does not really influence the performance as recent Samba versions are already optimized, but we will see. 6.) Choose a proper SSD for your cache You could use Unraid without an SSD, but if you want fast SMB transfers an SSD is absolutely required. Else you are limted to slow parity writes and/or through your slow HDD. But many SSDs on the market are not "compatible" for using it as an Unraid SSD Cache. DRAM Many cheap models do not have a DRAM Cache. This small buffer is used to collect very small files or random writes before they are finally written to the SSD and/or is used to have a high speed area for the file mapping-table. In Short, you need DRAM Cache in your SSD. No exception. SLC Cache While DRAM is only absent in cheap SSDs, SLC Cache can miss in different price ranges. Some cheap models use a small SLC cache to "fake" their technical data. Some mid-range models use a big SLC Cache to raise durability and speed if installed in a client pc. And some high-end models do not have an SLC Cache, as their flash cells are fast enough without it. Finally you are not interested in SLC Cache. You are only interested in continuous write speeds (see "Verify Continuous Writing Speed") Determine the Required Writing Speed But before you are able to select the right SSD model you need to determine your minimum required transfer speed. This should be simple. How many ethernet ports do you want to use or do you plan to install a faster network adapter? Lets say you have two 1G ports and plan to install a 5G card. With SMB Multichannel its possible to use them in sum and as you plan to install a 10G card in your client you could use 7G in total. Now we can calculate: 7G * 117.5 MByte/s (real throughput per 1G ethernet) = 822 MByte/s and by that we have two options: buy one M.2 NVMe (assuming your motherboard has such a slot) with a minimum writing speed of 800 MByte/s buy two or more SATA SSDs and use them in a RAID0, each with a minimum writing speed of 400 MByte/s Verify Continuous Writing Speed of the SSD As an existing "SLC Cache" hides the real transfer speed you need to invest some time to check if your desired SSD model has an SLC cache and how much the SSD throttles after its full. A solution could be to search for "review slc cache" in combination with the model name. Using the image search could be helpful as well (maybe you see a graph with a falling line). If you do not find anything, use Youtube. Many people out there test their new ssd by simply copying a huge amount of files on it. Note: CrystalDiskMark, AS SSD, etc Benchmarks are useless as they only test a really small amount of data (which fits into the fast cache). Durability You could look for the "TBW" value of the SSD, but finally you won't be able to kill the SSD inside the warranty as long your very first filling of your unraid server is done without the SSD Cache. As an example a 1TB Samsung 970 EVO has a TBW of 600 and if your server has a total size of 100TB you would waste 100TBW on your first fill for nothing. If you plan to use Plex, think about using the RAM as your transcoding storage which would save a huge amount of writes to your SSD. Conclusion: Optimize your writings instead of buying an expensive SSD. NAS SSD Do not buy "special" NAS SSDs. They do not offer any benefits compared to the high-end consumer models, but cost more. 7.) More RAM More RAM means more caching and as RAM is even faster than the fastest SSDs, this adds additional boost to your SMB transfers. I recommend installing two identical (or more depening on the amount of slots) RAM modules to benefit from "Dual Channel" speeds. RAM frequency is not as important as RAM size. Read Cache for Downloads If you download a file twice, the second download does not read the file from your disk, instead it uses your RAM only. The same happens if you're loading covers of your MP3s or Movies or if Windows is generating thumbnails of your photo collection. More RAM means more files in your cache. The read cache uses by default 100% of your free RAM. Write Cache for Uploads Linux uses by default 20% of your free RAM to cache writes, before they are written to the disk. You can use the Tips and Tweaks Plugin to change this value or add this to your Go file (with the Config Editor Plugin) sysctl vm.dirty_ratio=20 But before changing this value, you need to be sure to understand the consequences: Never use your NAS without an UPS if you use write caching as this could cause huge data loss! The bigger the write cache, the smaller the read cache (so using 100% of your RAM as write cache is not a good idea!) If you upload files to your server, they are 30 seconds later written to your disk (vm.dirty_expire_centisecs) Without SSD Cache: If your upload size is generally higher than your write cache size, it starts to cleanup the cache and in parallel write the transfer to your HDD(s) which could result in slow SMB transfers. Either you raise your cache size, so its never filled up, or you consider totally disabling the write cache. With SSD Cache: SSDs love parallel transfers (read #6 of this Guide), so a huge writing cache or even full cache is not a problem. But which dirty_ratio value should you set? This is something you need to determine by yourself as its completely individual: At first you need to think about the highest RAM usage that is possible. Like active VMs, Ramdisks, Docker containers, etc. By that you get the smallest amount of free RAM of your server: Total RAM size - Reserved RAM through VMs - Used RAM through Docker Containers - Ramdisks = Free RAM Now the harder part: Determine how much RAM is needed for your read cache. Do not forget that VMs, Docker Containers, Processes etc load files from disks and they are all cached as well. I thought about this and came to this command that counts hot files: find /mnt/cache -type f -amin -86400 ! -size +1G -exec du -bc {} + | grep total$ | cut -f1 | awk '{ total += $1 }; END { print total }' | numfmt --to=iec-i --suffix=B It counts the size of all files on your SSD cache that are accessed in the last 24 hours (86400 seconds) The maximum file size is 1GiB to exclude VM images, docker containers, etc This works only if you hopefully use your cache for your hot shares like appdata, system, etc Of course you could repeat this command on several days to check how it fluctuates. This command must be executed after the mover has finished its work This command isn't perfect as it does not count hot files inside a VM image Now we can calculate: 100 / Total RAM x (Free RAM - Command Result) = vm.dirty_ratio If your calculated "vm.dirty_ratio" is lower than 5% (or even negative), you should lower it to 5 and buy more RAM. between 5% and 20%, set it accordingly, but you should consider buying more RAM. between 20% and 90%, set it accordingly If your calculated "vm.dirty_ratio" is higher than 90%, you are probably not using your SSD cache for hot shares (as you should) or your RAM is huge as hell (congratulation ^^). I suggest not to set a value higher than 90. Of course you need to recalcuate this value if you add more VMs or Docker Containers. #8 Disable haveged Unraid does not trust the randomness of linux and uses haveged instead. By that all encryptions processes on the server use haveged which produces extra load. If you don't need it, disable it through your Go file (CA Config Editor) as follows: # ------------------------------------------------- # disable haveged as we trust /dev/random # https://forums.unraid.net/topic/79616-haveged-daemon/?tab=comments#comment-903452 # ------------------------------------------------- /etc/rc.d/rc.haveged stop
  46. 9 points
    This sums up my stance too. I can understand LimeTechs view as to why they didnt feel the need to communicate this to the other parties involved (as they never officially asked them to develop the solution they'd developed and put in place). But on the flip side the appeal of UnRaid is the community spirit and drive to implement things which make the platform more useful. It wouldnt have taken a lot to give certain members in community a heads up that this was coming, and to give credit where credit is due in the release notes. Something along the lines of: "After seeing the appeal and demand around 3rd party driver integration with unraid as its matured over recent years we've introduced a mechanism to bring this into the core OS distribution. We want to thank specific members of the community such as @CHBMB and @bass_rock who've unofficially supported this in recent times and which drove the need to implement this in a way which allows better support for the OS as a whole for the entire community, and remove the need for users to use unofficial builds." Also for them to be given a heads up and at least involved in the implementation stages at an advisory or review level as well... Anyway, I hope this communication mishap can be resolved. It was obviously not intentional, and 2020 as a whole has meant we're all stressed and overworked (I am anyway!), so it makes situations like this a lot easier to trigger. Hopefully lessons can be learned here and changes similar to this can be managed with a little more community involvement going forward.
  47. 9 points
    Install the referenced plugin. It will install the Nvidia driver and tools needed for transcoding in Docker containers. If you don't care about this, no need to deal with it. The plugin is more of a "work in process" right now and will mature over time, including being added to Community Apps. We didn't include the Nvidia vendor driver built-in to the release for several reasons: The package is very large, over 200MB and no need for everyone to download this thing if they don't need it. Including the driver "taints" the Linux kernel. There is something of a longstanding war between the Linux community and Nvidia because large parts of the Nvidia are not open source. Due to how the driver has to integrate into the kernel, this "taints" the kernel. For us it means if we have an kernel-related issues, no developer will help out if they see the kernel is tainted. Also don't want that message appearing in syslog by default The Nvidia driver might change faster than we want to update Linux kernel. In this case we can build and publish a new driver independent of Unraid OS release.
  48. 9 points
    Use extra Unraid CPU or GPU computing power to help take the fight to COVID-19 with BOINC or Folding@Home! https://unraid.net/blog/help-take-the-fight-to-covid-19-with-boinc-or-folding-home Stay safe everyone. -Spencer
  49. 9 points
    At times you will want to "hide" devices from Unraid so that they can be passed through to a VM. Unraid Prior to 6.7 In the past (pre Unraid 6.7) we would stub the device by adding a Vendor:Device code to the vfio-pci.ids parameter in Syslinux, something like this: append vfio-pci.ids=8086:1533 This worked, but had several downsides: If you have multiple devices with the same Vendor:Device code, all of them would be stubbed (hidden) from Unraid It is a fairly technical process to find the right Vendor:Device code and modify the syslinux file. Make a mistake and your system won't boot! As an alternative, you could add the <Domain:Bus:Device.Function> string to the xen-pciback.hide parameter in Syslinux: append xen-pciback.hide=0000:03:00.0 This had downsides too: Still a technical / risky process If you add/remove hardware after modifying syslinux, the pci address could change and the wrong device could end up being stubbed. This would cause problems if a critical disk controller or NIC were suddenly hidden from Unraid This broke in Unraid 6.7. More details Unraid 6.7 Starting with Unraid 6.7 we could bind devices to the vfio-pci driver based on the <Domain:Bus:Device.Function> string (aka pci address). You needed to manually modify the config/vfio-pci.cfg file and specify the <Domain:Bus:Device.Function> string, like this: BIND=03:00.0 This worked, but still had several downsides: It was a fairly technical process to find the right string to place in the file. But at least if anything went wrong you could simply delete the config file off the flash drive and reboot. We still had the problem where if you add/remove hardware after modifying the file, the pci addresses could change and the wrong device could end up being bound to vfio-pci Unraid 6.9 For Unraid 6.9, Skittals has incorporated the excellent "VFIO-PCI Config" plugin directly into the Unraid webgui. So now from the Tools -> System Devices page you can easily see all of your hardware and which IOMMU groups they are in. Rather than editing the config file by hand, simply add a checkbox next to the devices that you want to bind to vfio-pci (aka hide from Unraid). If a device is being used by Unraid (such as a USB controller, disk controller, etc) then the web interface will prevent you from selecting it. Additionally, we have a new version of the underlying vfio-pci script which can prevent the wrong devices from being bound when hardware is added or removed. When you click to bind a device on the System Devices page, it will write both the <Domain:Bus:Device.Function> and the <Vendor:Device> code to the config file, like this: BIND=0000:03:00.0|8086:1533 In this example, the updated script will bind the device at pci address 0000:03:00.0, but only if the <Vendor:Device> code is 8086:1533. If a different <Vendor:Device> code is found at that address, it will not bind. This means we will never inadvertently bind a device that is important to Unraid! (However, since the desired device is not available to be bound, the VM expecting that device may not function correctly.) Devices bound in this way can be passed through to your VMs by going to the VM tab, editing the template, and then selecting the appropriate device from one of the hardware dropdowns. Can't find it? Check under "Other PCI Devices". If the System Devices page shows that multiple devices are in the same IOMMU group, it will automatically bind all the devices in that group to vfio-pci. You should then pass all devices in that IOMMU group to the same VM. Note: If you make hardware changes after setting this up, it would be a good idea to disable autostart on your VMs first. Then shutdown, add/remove hardware as needed, and boot back into Unraid. Visit the Tools -> System Devices page and ensure the correct devices are still being bound to vfio-pci. Adjust as needed and reboot, then start your VMs. Troubleshooting Tips If you had the VFIO-PCI Config plugin installed, you should remove it as that functionality is now built-in to Unraid 6.9 General tip for Unraid - if you intend to try something that feels risky, go to Settings -> Disk Settings and disable Array Auto Start before you shutdown. This will minimize the chance of data loss on boot. If all goes well you can start the array up after booting. If you bind your only video card then Unraid probably won't boot. See the next point. The System Devices page writes the device details to config/vfio-pci.cfg file on the flash drive. If you ever want to "start fresh" simply delete this file and reboot. (New in beta24) If there was a vfio-pci.cfg file to process during boot, System Devices will include a "View VFIO-PCI Log" button that details each of the devices that were (un)successfully bound during boot, along with any available error messages. Be sure to upload your diagnostics ( Tools -> Diagnostics ) when requesting help as both the config file and the log are included in it Hopefully this is helpful Feel free to let me know in the comments if anything is unclear or wrong.
  50. 9 points
    A fairly large kernel update was published yesterday as was a new WireGuard release and I thought it important to update and sanity-check. We'll let this bake over the weekend and if no new big issue shows up we'll publish to stable. Then we can move on to the 5.4 kernel in Unraid 6.9. -rc9 summary: Update kernel to 4.19.88. Update to latest WireGuard release Other package updates. Specific changes in [-rcN] are indicated in bold below. New in Unraid OS 6.8 release: The unRAIDServer.plg file (update OS) still downloads the new release zip file to RAM but then extracts directly to USB flash boot device. You will probably notice a slight difference in speed of extract messages. [-rc2] The 'sync' command at the end has been replaced with 'sync -f /boot'. Forms based authentication If you have set a root password for your server, when accessing webGUI you'll now see a nice login form. There still is only one user for Unraid so for username enter root. This form should be compatible with all major password managers out there. We always recommend using a strong password. [-rc2] There is no auto-logout implemented yet, please click Logout on menu bar or completely close your browser to logout. Linux kernel [-rc8] Remains on 4.19 [-rc6/-rc7] include latest Intel microcode for yet another hardware vulnerability mitigation. default scheduler now 'mq-deadline' [-rc2] but this can be changed via Settings/Disk Settings/Scheduler setting. enabled Huge Page support, though no UI control yet binfmt_misc support added "Vega 10 Reset bug" [-rc2] and 'navi-reset' patches removed [-rc5] [-rc2] added oot: Realtek r8125: version 9.002.02 [-rc3] additional md/unraid changes and instrumentation [-rc6] fix chelsio missing firmware [-rc8] removed Highpoint r750 driver [does not work] md/unraid driver Introduced "multi-stream" support: Reads on devices which are not being written should run at full speed. In addition, if you have set the md_write_method tunable to "reconstruct write", then while writing, if any read streams are detected, the write method is switched to "read/modifywrite". Parity sync/check should run at full speed by default. Parity sync/check is throttled back in presence of other active streams. The "stripe pool" resource is automatically shared evenly between all active streams. As a result got rid of some Tunables: md_sync_window md_sync_thresh and added some tunables: md_queue_limit md_sync_limit [-rc2] md_scheduler Please refer to Settings/Disk Settings help text for description of these settings. WireGuard support - available as a plugin via Community Apps. Our WireGuard implementation and UI is still a work-in-process; for this reason we have made this available as a plugin, though the latest WireGuard module is included in our Linux kernel. Full WireGuard implementation will be merged into Unraid OS itself in a future release. I want to give special thanks to @bonienl who wrote the plugin with lots of guidance from @ljm42 - thank you! I also should give a shout out to @NAS who got us rolling on this. If you don't know about WireGuard it's something to look into! Guide here: WS-Discovery support - Finally you can get rid of SMBv1 and get reliable Windows network discovery. This feature is configured on the Settings/SMB Settings page and enabled by default. Also on same settings page is Enable NetBIOS setting. This is enabled by default, however if you no longer have need for NetBIOS discovery you can turn it off. When turned off, Samba is configured to accept only SMBv2 protocol and higher. Added mDNS client support in Unraid OS. This means, for example, from an Unraid OS terminal session to ping another Unraid OS server on your network you can use (e.g., 'tower'): ping tower.local instead of ping tower Note the latter will still work if you have NetBIOS enabled. User Share File System (shfs) changes: Integrated FUSE-3 - This should increase performance of User Share File System. Fixed bug with hard link support. Previously a 'stat' on two directory entries referring to same file would return different i-node numbers, thus making it look like two independent files. This has been fixed however there is a config setting on Settings/Global Share Settings called "Tunable (support hard links)". [-rc2 ] Fixed the default value Yes, but with certain very old media and DVD players which access shares via NFS, you may need to set this to No. [-rc5] Fixed not accounting for devices not mounted yet. Note: if you have custom config/extra.cfg file, get rid of it. Other improvements/bug fixes: Format - during Format any running parity sync/check is automatically Paused and then resumed upon Format completion. Encryption - an entered passphrase is not saved to any file. Fixed bug where multi-device btrfs pool was leaving metadata set to dup instead of raid1. Several other small bug fixes and improvements. [-rc5] Fixed bug where quotes were not handled properly in passwords. Numerous base package updates [-rc2] including updating PHP to version 7.3.x, Samba to version 4.11.x. Known Issues and Other Errata Some users have reported slower parity sync/check rates for very wide arrays (20+ devices) vs. 6.7 and earlier releases - we are still studying this problem. [-rc6] this is fixed: If you are using Unassigned Devices plugin with encrypted volumes, you must use the file method of specifying the encryption passphrase. Note that a file containing your passphrase must consist of a single null-terminated string with no other line ending characters such as LF or CR/LF. In another step toward better security, the USB flash boot device is configured so that programs and scripts residing there cannot be directly executed (this is because the 'x' bit is set now only for directories). Commands placed in the 'go' file still execute because during startup, that file is copied to /tmp first and then executed from there. If you have created custom scripts you may need to take a similar approach. AFP is now deprecated and we plan to remove support in Unraid 6.9 release. A note on password strings Password strings can contain any character however white space (space and tab characters) is handled specially: all leading and trailing white space is discarded multiple embedded white space is collapsed to a single space character. By contrast, encryption passphrase is used exactly as-is. Version 6.8.0-rc9 2019-12-06 Base distro: btrfs-progs: version 5.4 ca-certificates: version 20191130 ebtables: version 2.0.11 gnutls: version 3.6.11.1 gtk+3: version 3.24.13 iproute2: version 5.4.0 iptables: version 1.8.4 keyutils: version 1.6 libepoxy: version 1.5.4 libnftnl: version 1.1.5 librsvg: version 2.46.4 libtasn1: version 4.15.0 lvm2: version 2.03.07 nano: version 4.6 pcre2: version 10.34 pkgtools: version 15.0 build 28 wireguard: version 0.0.20191205 xorg-server: version 1.20.6 Linux kernel: version 4.19.88