• Unraid OS version 6.9.0-beta24 available


    limetech

    6.9.0-beta24 vs. -beta22 Summary:

    • fixed several bugs
    • added some out-of-tree drivers
    • added ability to use xfs-formatted loopbacks or not use loopback at all for docker image layers.  Refer to Docker section below for more details
    • (-beta23 was an internal release)

     

    Important: Beta code is not fully tested and not feature-complete.  We recommend running on test servers only!

     

    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 must be up to date to install languages.  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.

     

    These out-of-tree drivers are currently included:

    • QLogic QLGE 10Gb Ethernet Driver Support (from staging)
    • RealTek r8125: version 9.003.05 (included for newer r8125)
    • HighPoint rr272x_1x: version v1.10.6-19_12_05 (per user request)

    Note that as we update Linux kernel, if an out-of-tree driver no longer builds, it will be omitted.

     

    These drivers are currently omitted:

    • Highpoint RocketRaid r750 (does not build)
    • Highpoint RocketRaid rr3740a (does not build)
    • Tehuti Networks tn40xx (does not build)

    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

     

    We also made some changes to add flexibility in assigning storage for the Docker engine.  First, 'rc.docker' will detect the filesystem type of /var/lib/docker.  We now support either btrfs or xfs and the docker storage driver is set appropriately.

     

    Next, 'mount_image' is modifed to support loopback formatted either with btrfs or xfs depending on the suffix of the loopback file name.  For example, the file name ends with ".img", as in "docker.img" then we use mkfs.btrfs.  If file name ends with "-xfs.img", as in "docker-xfs.img" then we use mkfs.xfs.


    We also added the ability to bind-mount a directory instead of using a loopback.  If file name does not end with ".img" then code assumes this is the name of directory (presumably on a share) which is bind-mounted onto /var/lib/docker.

     

    For example, if "/mnt/user/system/docker/docker" then we first create, if necessary the directory "/mnt/user/system/docker/docker".  If this path is on a user share we then "dereference" the path to get the disk path which is then bind-mounted onto /var/lib/docker.  For exmaple, if "/mnt/user/system/docker/docker" is on "disk1", then we would bind-mount "/mnt/disk1/system/docker/docker".  Caution: the share should be cache-only or cache-no so that 'mover' will not attempt to move the directory, but the script does not check this.

     

    In this release however, you must edit the 'config/docker.cfg' file directly to specify a directory, for example:

    DOCKER_IMAGE_FILE="/mnt/user/system/docker/docker"

     

    Finally, it's 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.  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-beta24 2020-07-08

     

    Bug fixes:

    • fix emhttpd crash expanding number of slots for an existing pool
    • fix share protected/not protected status
    • fix btrfs free space reporting
    • fix pool spinning state incorrect

     

    Base distro:

    • curl: version 7.71.0
    • fuse3: version 3.9.2
    • file: version 5.39
    • gnutls: version 3.6.14
    • harfbuzz: version 2.6.8
    • haveged: version 1.9.12
    • kernel-firmware: version 20200619_3890db3
    • libarchive: version 3.4.3
    • libjpeg-turbo: version 2.0.5
    • lcms2: version 2.11
    • libzip: version 1.7.1
    • nginx: version 1.19.0 (CVE-2019-9511, CVE-2019-9513, CVE-2019-9516)
    • ntp: version 4.2.8p15
    • openssh: version 8.3p1
    • pam: version 1.4.0
    • rsync: version 3.2.1
    • samba: version 4.12.5 (CVE-2020-10730, CVE-2020-10745, CVE-2020-10760, CVE-2020-14303)
    • shadow: version 4.8.1
    • sqlite: version 3.32.3
    • sudo: version 1.9.1
    • sysvinit-scripts: version 2.1
    • ttyd: version 20200624
    • util-linux: version 2.35.2
    • xinit: version 1.4.1
    • zstd: version 1.4.5

     

    Linux kernel:

    • version 5.7.7
    • out-of-tree driver: QLogic QLGE 10Gb Ethernet Driver Support (from staging)
    • out-of-tree driver: RealTek r8125: version 9.003.05
    • out-of-tree driver: HighPoint rr272x_1x: version v1.10.6-19_12_05

     

    Management:

    • cleanup passwd, shadow
    • docker: support both btrfs and xfs backing filesystems
    • loopbacks: permit xfs or btrfs based on filename
    • mount_image: suppport bind-mount
    • mount all btrfs volumes using 'space_cache=v2' option
    • mount loopbacks with 'noatime' option; enable 'direct-io'
    • non-rotational device partitions aligned on 1MiB boundary by default
    • ssh: require passwords, disable non-root tunneling
    • web terminal: inhibit warning pop-up when closing window
    • webgui: Add log viewer for vfio-pci
    • webgui: Allow different image types to upload with 512K max
    • webgui: other misc. improvements
    • webgui: vm manager: Preserve VNC port settings
    • Like 6
    • Thanks 3



    User Feedback

    Recommended Comments



    11 minutes ago, johnnie.black said:
    
    root@Test:~# stat -f /mnt/cache
      File: "/mnt/cache"
        ID: 98929008f93c43e2 Namelen: 255     Type: btrfs
    Block size: 4096       Fundamental block size: 4096
    Blocks: Total: 31266616   Free: 31207938   Available: 22859018
    Inodes: Total: 0          Free: 0

     

    A case can be made that the way we output is more "correct" than 'df' command because it takes into account the space used by raid5 parity - though not the case with raid1 😆.  My understanding was that 'df' just used statfs() system call but obviously it is reporting the wrong "Total" for raid5.

     

    The thing maddening about btrfs is their stubbornness in not accepting reality that different subvolumes cannot at this time have different "raid" levels (the design theoretically permits this).  Hence forever these free space reporting issues which does nothing but diminish confidence in btrfs. /rant

    • Haha 1
    Link to comment
    4 minutes ago, limetech said:

    Blocks: Total: 31266616 Free: 31207938

    Maybe you could use total-free to calculate used, in this case it would be about 240MB which is different than df reports but sounds about write for an empty fs, if you think that's a possibility I could run some test to see if it always reports the correct space for various profiles and usage scenarios, alternately, btrfs-progs 5.7 can finally report the correct stats from raid5/6 profiles with "btrfs fi usage", so maybe easier to get it from there once btrfs-progs are updated.

    Link to comment
    1 hour ago, johnnie.black said:

    Maybe you could use total-free to calculate used, in this case it would be about 240MB which is different than df reports but sounds about write for an empty fs, if you think that's a possibility I could run some test to see if it always reports the correct space for various profiles and usage scenarios, alternately, btrfs-progs 5.7 can finally report the correct stats from raid5/6 profiles with "btrfs fi usage", so maybe easier to get it from there once btrfs-progs are updated.

    I'm inclined to not mess with this further.  There are probably not very many users out there using btrfs raid5/6 and there is a patch set supposedly addressing this (perhaps):

    https://patchwork.kernel.org/patch/11318725/

     

    Although I don't see this patch included in 5.8-rc source.

    Link to comment
    2 hours ago, johnnie.black said:

    Maybe you could use total-free to calculate used, in this case it would be about 240MB which is different than df reports but sounds about write for an empty fs, if you think that's a possibility I could run some test to see if it always reports the correct space for various profiles and usage scenarios, alternately, btrfs-progs 5.7 can finally report the correct stats from raid5/6 profiles with "btrfs fi usage", so maybe easier to get it from there once btrfs-progs are updated.

    Hey looking at source of 'df' command, looks like they use 'statvfs()' instead of 'statfs()' - I'll give that a go.

    • Like 1
    Link to comment
    4 hours ago, limetech said:

    This bug is fixed in next release.  You can disable NFS to workaround for now.  If that's not desirable then it's best for you to downgrade but first:

     

    1. Download a flash backup just to be safe: Main/Flash/Flash Backup

     

    2. Then from Terminal:

    
    mv /boot/config/disk.cfg.bak /boot/config/disk.cfg
    rm -r /boot/config/pools

    Once disable NFS then array start / stop problem fixed.

    But SSH network access and maintenance mode FS read check still not work, so I fallback to beta1 finally.

    Link to comment

    The GUI creates an xfs image with docker-xfs.img but docker service doesn't start with the xfs image.

     

    This is what it says in the log.

    Jul  9 23:51:33 tower emhttpd: shcmd (504): /usr/local/sbin/mount_image '/mnt/cache/docker/docker-xfs.img' /var/lib/docker 64
    Jul  9 23:51:33 tower root: Creating new image file: /mnt/cache/docker/docker-xfs.img size: 64G
    Jul  9 23:51:33 tower root: meta-data=/mnt/cache/docker/docker-xfs.img isize=512    agcount=4, agsize=4194304 blks
    Jul  9 23:51:33 tower root:          =                       sectsz=512   attr=2, projid32bit=1
    Jul  9 23:51:33 tower root:          =                       crc=1        finobt=1, sparse=1, rmapbt=0
    Jul  9 23:51:33 tower root:          =                       reflink=1
    Jul  9 23:51:33 tower root: data     =                       bsize=4096   blocks=16777216, imaxpct=25
    Jul  9 23:51:33 tower root:          =                       sunit=0      swidth=0 blks
    Jul  9 23:51:33 tower root: naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
    Jul  9 23:51:33 tower root: log      =internal log           bsize=4096   blocks=8192, version=2
    Jul  9 23:51:33 tower root:          =                       sectsz=512   sunit=0 blks, lazy-count=1
    Jul  9 23:51:33 tower root: realtime =none                   extsz=4096   blocks=0, rtextents=0
    Jul  9 23:51:33 tower kernel: XFS (loop3): Mounting V5 Filesystem
    Jul  9 23:51:33 tower kernel: XFS (loop3): Ending clean mount
    Jul  9 23:51:33 tower kernel: xfs filesystem being mounted at /var/lib/docker supports timestamps until 2038 (0x7fffffff)
    Jul  9 23:51:33 tower emhttpd: shcmd (506): /etc/rc.d/rc.docker start
    Jul  9 23:51:33 tower root: starting dockerd ...
    Jul  9 23:51:50 tower emhttpd: shcmd (508): umount /var/lib/docker
    Jul  9 23:51:50 tower kernel: XFS (loop3): Unmounting Filesystem

     

    Similarly changing the path to a folder creates what look like various docker related content in the folder but the service also fails to start.

     

    PS: changing the --storage-driver= in the docker.cfg file to overlay2 instead of btrfs makes the xfs image work i.e. docker service starts. I think you missed the part of the code to change the storage driver.

    Edited by testdasi
    Link to comment

    You should post your diagnostics.   I've got no problems creating a folder image

    Link to comment

    I passthrough an internal intel GPU (only GPU in the system) to my Windows10 vm, runs stable without problems.
    Since I updated to version 6.9.0-beta24 the vm doesn't start anymore and the screen stays black. If I set the graphics to vnc the vm runs without problems.

    Are there any suggestions why the vm doesn't start with passthroughed GPU?
    Thanks

    diagnostics-20200710-0749.zip

    Link to comment
    12 hours ago, testdasi said:

    I think you missed the part of the code to change the storage driver.

    The value of the storga-driver parameter is automatically detected and set as either "btrfs" or "xfs" when the docker service is started.

     

    What is the output of

    findmnt /var/lib/docker

     

    Link to comment
    1 hour ago, bonienl said:

    The value of the storga-driver parameter is automatically detected and set as either "btrfs" or "xfs" when the docker service is started.

     

    What is the output of

    
    findmnt /var/lib/docker

     

     

    So what I did:

    1. Change Enable Docker to No + Apply to turn off docker
    2. Change Docker vdisk location to /mnt/cache/docker/image/docker-xfs.img + Apply
    3. Change Enable Docker to Yes + Apply
    4. Wait for the thing to finish and check Docker tab which says "Docker Service failed to start."

     

    findmnt is blank because based on syslog, the mount is automatically umount after dockerd start, presumably because it fails. Syslog:

    Jul 10 14:17:21 Pinecloud-Oasis ool www[56379]: /usr/local/emhttp/plugins/dynamix/scripts/emcmd 'cmdStatus=Apply'
    Jul 10 14:17:21 Pinecloud-Oasis emhttpd: Starting services...
    Jul 10 14:17:21 Pinecloud-Oasis emhttpd: shcmd (1798): /etc/rc.d/rc.samba restart
    Jul 10 14:17:21 Pinecloud-Oasis winbindd[71252]: [2020/07/10 14:17:21.716771,  0] ../../source3/winbindd/winbindd.c:244(winbindd_sig_term_handler)
    Jul 10 14:17:21 Pinecloud-Oasis winbindd[71405]: [2020/07/10 14:17:21.716795,  0] ../../source3/winbindd/winbindd.c:244(winbindd_sig_term_handler)
    Jul 10 14:17:21 Pinecloud-Oasis winbindd[71253]: [2020/07/10 14:17:21.716784,  0] ../../source3/winbindd/winbindd.c:244(winbindd_sig_term_handler)
    Jul 10 14:17:21 Pinecloud-Oasis winbindd[71405]:   Got sig[15] terminate (is_parent=0)
    Jul 10 14:17:21 Pinecloud-Oasis winbindd[71252]:   Got sig[15] terminate (is_parent=1)
    Jul 10 14:17:21 Pinecloud-Oasis winbindd[71253]:   Got sig[15] terminate (is_parent=0)
    Jul 10 14:17:23 Pinecloud-Oasis root: Starting Samba:  /usr/sbin/smbd -D
    Jul 10 14:17:23 Pinecloud-Oasis root:                  /usr/sbin/winbindd -D
    Jul 10 14:17:23 Pinecloud-Oasis smbd[71732]: [2020/07/10 14:17:23.887379,  0] ../../lib/util/become_daemon.c:135(daemon_ready)
    Jul 10 14:17:23 Pinecloud-Oasis smbd[71732]:   daemon_ready: daemon 'smbd' finished starting up and ready to serve connections
    Jul 10 14:17:23 Pinecloud-Oasis winbindd[71739]: [2020/07/10 14:17:23.902056,  0] ../../source3/winbindd/winbindd_cache.c:3203(initialize_winbindd_cache)
    Jul 10 14:17:23 Pinecloud-Oasis winbindd[71739]:   initialize_winbindd_cache: clearing cache and re-creating with version number 2
    Jul 10 14:17:23 Pinecloud-Oasis winbindd[71739]: [2020/07/10 14:17:23.902535,  0] ../../lib/util/become_daemon.c:135(daemon_ready)
    Jul 10 14:17:23 Pinecloud-Oasis winbindd[71739]:   daemon_ready: daemon 'winbindd' finished starting up and ready to serve connections
    Jul 10 14:17:24 Pinecloud-Oasis emhttpd: shcmd (1813): /usr/local/sbin/mount_image '/mnt/cache/docker/image/docker-xfs.img' /var/lib/docker 64
    Jul 10 14:17:24 Pinecloud-Oasis root: Creating new image file: /mnt/cache/docker/image/docker-xfs.img size: 64G
    Jul 10 14:17:24 Pinecloud-Oasis root: meta-data=/mnt/cache/docker/image/docker-xfs.img isize=512    agcount=4, agsize=4194304 blks
    Jul 10 14:17:24 Pinecloud-Oasis root:          =                       sectsz=512   attr=2, projid32bit=1
    Jul 10 14:17:24 Pinecloud-Oasis root:          =                       crc=1        finobt=1, sparse=1, rmapbt=0
    Jul 10 14:17:24 Pinecloud-Oasis root:          =                       reflink=1
    Jul 10 14:17:24 Pinecloud-Oasis root: data     =                       bsize=4096   blocks=16777216, imaxpct=25
    Jul 10 14:17:24 Pinecloud-Oasis root:          =                       sunit=0      swidth=0 blks
    Jul 10 14:17:24 Pinecloud-Oasis root: naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
    Jul 10 14:17:24 Pinecloud-Oasis root: log      =internal log           bsize=4096   blocks=8192, version=2
    Jul 10 14:17:24 Pinecloud-Oasis root:          =                       sectsz=512   sunit=0 blks, lazy-count=1
    Jul 10 14:17:24 Pinecloud-Oasis root: realtime =none                   extsz=4096   blocks=0, rtextents=0
    Jul 10 14:17:24 Pinecloud-Oasis kernel: XFS (loop2): Mounting V5 Filesystem
    Jul 10 14:17:24 Pinecloud-Oasis kernel: XFS (loop2): Ending clean mount
    Jul 10 14:17:24 Pinecloud-Oasis kernel: xfs filesystem being mounted at /var/lib/docker supports timestamps until 2038 (0x7fffffff)
    Jul 10 14:17:24 Pinecloud-Oasis emhttpd: shcmd (1815): /etc/rc.d/rc.docker start
    Jul 10 14:17:24 Pinecloud-Oasis root: starting dockerd ...
    Jul 10 14:17:39 Pinecloud-Oasis emhttpd: shcmd (1817): umount /var/lib/docker
    Jul 10 14:17:39 Pinecloud-Oasis kernel: XFS (loop2): Unmounting Filesystem

     

    Running the mount command as shown on syslog manually shows:

    # /usr/local/sbin/mount_image '/mnt/cache/docker/image/docker-xfs.img' /var/lib/docker 64
    meta-data=/dev/loop2             isize=512    agcount=4, agsize=4194304 blks
             =                       sectsz=512   attr=2, projid32bit=1
             =                       crc=1        finobt=1, sparse=1, rmapbt=0
             =                       reflink=1
    data     =                       bsize=4096   blocks=16777216, imaxpct=25
             =                       sunit=0      swidth=0 blks
    naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
    log      =internal log           bsize=4096   blocks=8192, version=2
             =                       sectsz=512   sunit=0 blks, lazy-count=1
    realtime =none                   extsz=4096   blocks=0, rtextents=0

     

    Then findmnt shows:

    # findmnt /var/lib/docker
    TARGET          SOURCE     FSTYPE OPTIONS
    /var/lib/docker /dev/loop2 xfs    rw,noatime,attr2,inode64,logbufs=8,logbsize=32k,noquota

     

    cat docker.cfg shows storage driver still says btrfs

    # cat /boot/config/docker.cfg
    DOCKER_ENABLED="yes"
    DOCKER_IMAGE_FILE="/mnt/cache/docker/image/docker-xfs.img"
    DOCKER_IMAGE_SIZE="64"
    DOCKER_APP_CONFIG_PATH="/mnt/cache/docker/appdata/"
    DOCKER_APP_UNRAID_PATH=""
    DOCKER_OPTS="--storage-driver=btrfs"
    DOCKER_AUTHORING_MODE="no"
    DOCKER_CUSTOM_NETWORKS="eth1 "
    DOCKER_LOG_ROTATION="yes"
    DOCKER_LOG_SIZE="10m"
    DOCKER_LOG_FILES="3"
    DOCKER_USER_NETWORKS="preserve"

     

     

    Link to comment

    Wireguard not reporting handshake properly:

    6.9 Beta 24

    1527903753_Unraid6.9.beta24.png.f143f2384002a4d051d0e39d00d41094.png

    6.8.3

    59976792_Unraid6.8.3.png.100c850a97e91fc7055af7fe9d2871ff.png

    These two servers are connected and the VPN is working, but 6.9 does not show handshake activity.

    • Like 1
    Link to comment
    12 minutes ago, dlandon said:

    Wireguard not reporting handshake properly:

    6.9 Beta 24

    1527903753_Unraid6.9.beta24.png.f143f2384002a4d051d0e39d00d41094.png

    6.8.3

    59976792_Unraid6.8.3.png.100c850a97e91fc7055af7fe9d2871ff.png

    These two servers are connected and the VPN is working, but 6.9 does not show handshake activity.

    Im seeing this also. Its working properly just not showing.

    Link to comment
    31 minutes ago, testdasi said:

    DOCKER_OPTS="--storage-driver=btrfs"

    Remove that line altogether from the docker.cfg file  It's winding up overriding the system (and it's not present on my system at all)

     

    Probably @limetech / @bonienl should update the OS to ignore that

    • Like 1
    • Thanks 1
    Link to comment
    1 hour ago, dlandon said:

    Wireguard not reporting handshake properly:

    Please try version 2020.07.10a (just released)

    Link to comment
    59 minutes ago, Squid said:

    should update the OS to ignore that

    User should not preset this manually in the config file.

     

    Link to comment
    34 minutes ago, bonienl said:

    User should not preset this manually in the config file.

     

    I've seen it lots of times in diagnostics.   I think at one time it was automatically created in the cfg file

    Link to comment
    43 minutes ago, bonienl said:

    User should not preset this manually in the config file.

     

    As Squid said, I didn't set it. It was set automatically at some point.

     

    1 hour ago, Squid said:

    Remove that line altogether from the docker.cfg file  It's winding up overriding the system (and it's not present on my system at all)

     

    Probably @limetech / @bonienl should update the OS to ignore that

    Thank you. That was the reason then.

    Link to comment
    2 hours ago, david279 said:

    Im seeing this also. Its working properly just not showing.

    Now I see this:

    Wireguard.png.03b07c9ba6ccb80ba0d58139463d49d9.png

    What is '57 true, ago'?

    Link to comment
    24 minutes ago, dlandon said:

    Now I see this:

    Wireguard.png.03b07c9ba6ccb80ba0d58139463d49d9.png

    What is '57 true, ago'?

    Mine looks correct. 

     

    image.png.8ccf2200ad100bec63bf8a7f79606c62.png

    Link to comment
    41 minutes ago, david279 said:

    Mine looks correct. 

     

    image.png.8ccf2200ad100bec63bf8a7f79606c62.png

    That's the dashboard, not the Wireguard settings page that I show.

    Link to comment



    Guest
    This is now closed for further comments

  • Status Definitions

     

    Open = Under consideration.

     

    Solved = The issue has been resolved.

     

    Solved version = The issue has been resolved in the indicated release version.

     

    Closed = Feedback or opinion better posted on our forum for discussion. Also for reports we cannot reproduce or need more information. In this case just add a comment and we will review it again.

     

    Retest = Please retest in latest release.


    Priority Definitions

     

    Minor = Something not working correctly.

     

    Urgent = Server crash, data loss, or other showstopper.

     

    Annoyance = Doesn't affect functionality but should be fixed.

     

    Other = Announcement or other non-issue.