NAS

Moderators
  • Posts

    5040
  • Joined

  • Last visited

Posts posted by NAS

  1. Coincidentally I was thinking about this the other day along with S3 and it seems, to me at least, that whilst everyone will make a case for features they want, adding protocol support is the one sure fire way to attract new users. I cannot quantify how many users this would be but we can say that every user in the world that wants iSCSI or S3 doesnt buy unRAID.

     

    Seems like an "easy" win to me.

    • Upvote 2
  2. I cant see anything but I wanted to check to make sure since this is such a  long thread. I am in the process of migrating to XFS and I have found that one RFS disk that will mount happily with unraid wont mount at all with UD.

     

    dmesg shows

     

    [Tue Jun 19 15:40:36 2018] REISERFS warning (device sdc1): sh-2021 reiserfs_fill_super: can not find reiserfs on sdc1

     

    so before I get into this are there any know relevant issues?

     

    Update: well it turns out its pretty obvious why UD cant mount this reiser disk.... thats because it is xfs.

     

    # file -sL /dev/sdc*
    /dev/sdc:  DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 4294967295 sectors, extended partition table (last)
    /dev/sdc1: SGI XFS filesystem data (blksz 4096, inosz 512, v2 dirs)

     

    any ideas why UD is trying to mount a XFS disks as ResierFS?

     

     

  3.  

    https://raesene.github.io/blog/2016/03/06/The-Dangers-Of-Docker.sock/

     

    " After tweeting this article out @benhall pointed out that actually the ro setting on the volume mount doesn’t have a lot of effect in terms of security. An attacker with ro access to the socket can still create another container and do something like mount /etc/ into it from the host, essentially giving them root access to the host. So bottom line is don’t mount docker.sock into a container unless you trust its provenance and security… "

     

    In general security terms you know things are fundamentally not right with a generic approach when your trying to herd this many cats just to make it less insecure... not secure... less evil.

     

     

  4. There is always a risk of breakout of any container but this is the holy grail hack of such a system.

     

    But to be clear what this sock feature does. Essentially it gives the container root access as a member of the docker group on the HOST machine.... not the container... the host.

     

    This is a specific feature required by the traefik container and not required by almost any other container. It is very very very rare and for good reason.

     

  5. On 5/3/2017 at 5:43 PM, primeval_god said:

    Netdata can, but the docker container requires rw access to the docker.sock to do so . 

    If we are advocating the use of this container to fix a core OS limitation we need to explain the serious security implications of docker sock access. At the very least this will require a zone like setup with networking to mitigate some security risks.

     

    I would in my day job always advise strongly against any solution that could have public facing containers on the same instance as a backend sock instance

    • Like 1
  6. Any thoughts on this. Best case scenario is that it is PEBCAK but it doesnt seem to be obvious if it is. The only thing I can think off I do differernt than "some" is I often use "/mnt/cache" rather than "/mnt/user/" although I dont see why this would cause spin up on.

     

    As an illustration here is a before and after performing a single docker container stop. Notice the parity come up as well. Comparing write counts before and after (sorry I edited them out by mistake) I can see most of the RFS disks write count increase by 7 or 8. I am wondering if this is some sort of spin up caused by the docker container issuing a disk flush such as SYNC and RFS handing that differently than XFS.

     

    This is really annoying so any insight would be very much appreciated.

     

    before.thumb.jpg.4f3e4d7abf5dc2f2bd00a57934aa503c.jpg

     

    after.thumb.jpg.6edbfeed74b6af8af23ee55c9fc24ceb.jpg

  7. yes, if you are working with array files you should run mc as the typical array file owner nobody and not root.

     

    If you try to do this mc will complain without above fix.

     

    As a example of my usage for content only

     

    sudo -u nobody mc /mnt/user/downloads/ /mnt/user/movies/

     

  8. I am in the process of cleaning up years of unRAID tweaks.

     

    The way unRAID ships when you install mc and run it as "nobody" you have problems.

     

    This fixes it for me and some variation could probably fix it for everyone. I dont remember if mc is shipped native, if not it should be.

     

    #====================================================================================================
    #Fix mc running as nobody
    #====================================================================================================
    /usr/bin/mkdir -p /.cache/mc
    /usr/bin/mkdir -p /.local/share/mc
    /usr/bin/mkdir -p /.config/mc
    #====================================================================================================

     

     

  9. emHTTP bombed hard as soon as I hit reboot to apply the update here. Had to force a reboot from command line with the obvious consequences.

     

    I was having addon issues before hand though where updates would fail to apply due to the addon claiming not to be installed.

     

    Probably a me specific issue rather than a problem with the release.

     

    Update: my addon issue was specifically related to Advanced Buttons deprecation which I was sure i removed but somehow had not. Fix here

     

    • Upvote 1
  10. LT are wrong then :P But seriously I think all we need here is normal nix separation of error states. The reason I bring this up is that after manually tracking down where cache space had gone i noticed that i have had mover errors for weeks so this is based on real world issues.

     

    Also it is not my experience here that it only runs once but PECAK is entirely feasible. Will pay more attention and report back.

     

    :)

     

  11. Some quick feedback. I am new to this plugin.

     

    First off my compliments. It is super useful and very powerful

     

    Couple of enhancements for consideration:

     

    • we suggest turning off mover logging which makes sense except that it also removes mover error logging.. we should not be hiding errors. not sure what the best fix would be here.
    • when you enter the settings dialogue it actually kicks off a scan. I would suggest this is a break with the GUI design model and that entering settings should be limited to just that. Activating a scan should be a positive user action especially since it can take tens of minutes to complete.

    Kudos

  12. 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.

    • Like 2
  13. 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

     

     

     

     

  14. 7 hours ago, ljm42 said:

    USE_SSL="auto" PORT="80" PORTSSL="443"

    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)