Jump to content

limetech

Administrators
  • Posts

    10,186
  • Joined

  • Last visited

  • Days Won

    196

Report Comments posted by limetech

  1. 4 minutes ago, eoghan said:

    Ill do that cheers although I would love to know why with this update that the URL that I have set in 6.9 suddenly changes in this update to something completely different to what's set.

     

    What URL are you referring to?  Also you should be able to go to Update OS page and select to install the previous release.

  2. 12 hours ago, peter76 said:

    okay thats true for 6.10.0-rc1,
    but in 6.9.2 I had user shares enabled - and they where disabled in 6.10.0-rc1:
    grafik.png.15f4baf1db2f1f7054d6c303bfc0f6a2.png

     

    grafik.png.977d8118ec2e4ae3aab5cfaaba6327b5.png

     

    grafik.png.c54c36e2505e48e9c290576a934c5e55.png

     

    I could fix the problem - but less experienced users could have the same issue - and they get DOCKER and LIBVIRT (and maybe other) problems without a warning, and without a hint how to fix it.

     

    EDIT: yes this is a bug introduced in a change that set new user shares to not be exported by default - changed one too many share-related settings.  But below applies and how it's supposed to work.  In your case to solve this to Settings/Global Share Settings and enable user shares.  sorry about that.

     

    The "new defaults" only have to do with new configurations, they are not changed by updating to this release with one exception.  The issue I see in diags is that your 'config/share.cfg' file is simply absent.  Not sure what could have happened to it.  Do you see that file in your flash backup?

     

    Exception: on Management Access page, the default for "Use SSL/TLS" is "Auto" but that is incompatible with other changes we made in this area having to do with Let's Encrypt SSL certs.  If a server is upgraded to 6.10 and that setting is set to "Auto" and a LE cert does not exist, then we will set the variable to "no" (which is how it behaves with these conditions in 6.9 anyway).

  3. On 7/28/2021 at 6:28 AM, chris0583 said:

    I hate silence from tech companies.  At least give some BS canned answer like "we are looking into the issue".  When you email support they say go to the forums and check..........  🙄

    Sorry I've been head down in development and other responsibilities the last couple of months and didn't see this until a developer we've been working with pointed it out.

     

    We don't always have all the answers but you'll get no B.S. from me and you can always email directly:

    [email protected]

  4. 3 hours ago, bonienl said:

    The current implementation in the GUI is a kind of a hack. Before starting the long self-test it will change the spin-down timer setting to "never" and restores it to original setting once the self-test is completed. Though setting restoral doesn't always work.

     

    If you plan changes, we should address the GUI too and make it a proper solution inline with emhttpd.

     

     

    I, umm..., ripped that code out, I think for 6.9.1?   maybe 6.9.0.

  5. 6 hours ago, bonienl said:

    Apr 8 12:07:12 vesta emhttpd: read SMART /dev/sdb

     

    That message is output as a result of seeing I/O on partition 1 of the device.  That is, code has detected I/O counters have incremented since the last time they were checked (polled every second).  If there has been I/O to partition 1 then we assume the device must be spun-up.  The 'read SMART' command is then issued to get the device temperature.

     

    Specifically it looks at

    /sys/block/sdb/sdb1/stat

     

    Then adds the 3rd and 7th values (sectors read and sectors written).

     

    I don't see this happening on my test servers, but I don't have any SAS devices.

  6. 7 minutes ago, bonienl said:

    There is an interesting kernel bug fix, which looks like our case https://lkml.org/lkml/2021/3/29/499

     

    I don't know if this already available in a linux version for Unraid, perhaps @limetech can tell?

     

    Interesting.  Unraid OS 6.9.1 is on kernel 5.10.21 and the referenced patch is not applied.  Upcoming 6.9.2 release is on kernel 5.10.27 which does have the patch.  Working on finalizing the release now.

    • Like 1
    • Thanks 4
  7. Very interesting.  To fix, open a Terminal window and type:

    echo 'shfsExtra="-o default_permissions"' > /boot/config/extra.cfg

    Then you must Stop/Start array.  Also this will persist across reboots, hence to undo you must delete the file.

     

    This is a mount option that tells FUSE to let the kernel handle file system permissions.  This used to be how FUSE worked by default and somewhere along the line it got changed, probably in transition from FUSE v2 to v3.  This bug will get fixed in Unraid OS 6.10 where we can have a little beta testing before wider deployment.

     

     

    • Like 1
×
×
  • Create New...