• Content count

  • Joined

  • Last visited

Community Reputation

27 Good

About NAS

  • Rank
    Advanced Member


  • Gender
  1. CVE-2018-1057: Unprivileged user can change any user (and admin) password Caveats and further info here
  2. Sorry for the slow reply. I actually had this installed but did not realize it covered dockers as well. I still think this should be a standard feature but you have to choose your battles especially when such a good plugin exists... deja vu conversation. Thanking you saarg
  3. There are certain containers I do not wish to always update due to either their risk of breakage or required uptime. A good example is TVheadend which is known for breaking and updating turns of home TVs. Currently the only way i know to not update this container is to stop using the "update all" feature and manually update each remaining containers manually one by one. This is a chore and ideally specific containers could be excluded from "update all" or set to to only update every xx days/weeks.
  4. Security flaw discovered in Intel chips.

    Here we go again
  5. Sounds good. I think it makes more sense this way.
  6. That makes more sense however i would still recommend against casually manually suggesting editing a system config file that is controlled by the gui. Exceptional circumstances likely preclude this ever happening though so in that light some more context and warnings need applied. here be dragons It also needs clarity that the no SSL settings does not mean no SSL port good work
  7. Couple of thoughts on OP. Do we want to be suggesting using notepad or console when the GUI controls this file and does these changes for you? Do we really need to tell people to reboot the entire server perhaps there is a softer way? It does not work for me via the gui or by hand anyway. The best I can achieve is when it is set to this USE_SSL="no" PORT="80" PORTSSL="443" port 443 is still held by nginx and trys to redirects to 80 e.g. 443/tcp open ssl/http nginx |_http-server-header: nginx |_http-title: Did not follow redirect to http://TOWER.local:80/ which makes me think it really does mean "dont use SSL" but still listen for it and force to non TLS. I dont think this is the natural assumption of a "disable" SSL option? Edit: confirmed if i change the SSL port via the GUI and change SSL as well i can disable SSL without rebooting. This is better albeit i still question why there is no option to stop listening on the port. (perhaps PEBCAK TBC)
  8. Security flaw discovered in Intel chips.

    We have to be careful when we say things like this now. Unfortunately the days when this was really true are long gone, doubly so due to ransomware. Modern "Security in depth" practices call for essentially a "patch everything" policy because devices, people and WLAN are so ubiquitous now it is really just a matter of when, rather than if, a bad actor gains some foothold code in a "secure" private LAN. Terrible I know but thats the modern reality.
  9. My opinion for what it is worth. Drop the RC tag. It is meaningless here but meaningful everywhere else, leading only to avoidable confusion and complaints. Have two branches. One testing and one release. Patch the release branch until the testing branch is ready to take it over and then start again. This culture we have developed where months pass without any bug or security fixes being released is completely unprofessional. I am happy to return to assisting with security reports but not unless we adopt the two branch model or radically reduce the time between "stable" releases.
  10. Support for docker network?

    Its definitely an idea although I personally think that the rate of docker development is such that at some point we will need to move to including a dedicated upstream GUI.
  11. Support for docker network?

  12. Preclear plugin

    Polite bump for (it wont let me quote a quote... silly forum :): tl;dr Even when 100% successfully complete, a preclear run done via the unassigned devices addon only ever has the "cancel" option. Expected behavior would be that cancel state is removed when complete and drive status image changes to pre-cleared.
  13. Agree. This would be ideal but it is disingenuous of me to assume that these wasnt a good reason that this scheme was used in the first place and the same complications still exist today. I think this is the one change that needs to happen soon. My focus on this topic is driven by a strong potential of user data loss and whilst there is an inelegance to users having two types of almost identical disks that are not fully compatible that is an issue that can be addressed in the longer term (much as it irks me about all the time I have wasted moving data to standardize on XFS disks only to now find they are still non standard) I agree here as well and this wording puts a finger on one point I was struggling to make. Also it is important to accept that there is a real difference between the mindset of a user bringing a disk from elsewhere (importing) and one plugging in a disk created on unRAID (native). The user that has stayed native during the whole story may not even think to consider that there may be issues and that is where things can go badly wrong.
  14. @Squid to be fair I specifically and intentionally never said it was a bug in UD for three reasons, 1. I didn't know enough to comment, 2. to the user it makes no difference anyway and 3. I really didn't want to start pointing as that only deflects from the issue.... but that plan kinda back fired lol Anyways based on what I know so far I have to agree with the general sentiment that this must change and soon. It is without question a requirement that there should be absolute compatibility between UD formatted disks and unRAID and if a new common ground needs agreed that better fits with norms then it needs to happen soon. But I stand by my assertation that this is a bug, even if it is intentional and the code is sound; we simply cant have a situation where users can make a simple assumption/mistake and lose a disk of data with one button click. Whatever you need from me you have it because this needs to go away before someone gets hurt.
  15. The bug is that there are scenarios where disks with data could end up being erased. These might be rare but data safety trumps everything. I have not looked into it more since I had a backup to use to recover but I have here (still I think) a disk that was full of data and has ended up unmountable by unRAID and UD. It was (created using UD, mounted using UD, rsync using unRAID, umount using UD and then added to array but not mounted as the format warning stopped me. Also as far as I know unRAID cannot format a disk outside of the array? and if you add it to the array you can no longer remove it without a parity outage. The warning is a good step and I appreciate it as it will no doubt save others. Perhaps someone can explain or point me at more detail as to what is so special about unRAIDs' XFS format options that we cant replicate it? I would rather expend time on a direct fix than a work around or recap of where we were

Copyright © 2005-2017 Lime Technology, Inc. unRAIDĀ® is a registered trademark of Lime Technology, Inc.