• Posts

  • Joined

  • Last visited

  • Days Won


Report Comments posted by ken-ji

  1. 4 hours ago, sjaak said:


    You know that manual created files in /tmp will be gone after reboot? unless you created a script that create the file at boot...


    i personally recommended not to use /tmp for Plex etc. its better to use /dev/shm/

    /tmp is full RAM, /dev/shm/ is 1/2 RAM..

    Strictly speaking

    /tmp is not a standalone filesystem - its part of /, but / is also 1/2 total ram by default, unless you adjusted it.


  2. This is actually by design with Docker. We've discussed this at length before and your options each with their own caveats are:

    1. enable host access to docker networks in the Settings | Docker (Advanced View)
      my screenshot is disabled since I don't use it
    2. Enable VLANs in Settings | Network Settings
      and add custom networks in Docker settings
    3. If you have a spare Network card, you can keep it separate from the default bond between the other network interfaces (usually bond0) and then setup a custom network there for docker

    It is best to setup Unraid so it only has an IP in an interface that is not the same as the one being used by docker else the issue with connectivity will occur
    Some older threads for more details:



    • Thanks 1
  3. @limetech

    Seems like a bug with shfs itself:

    root@MediaStore:/mnt/user/Downloads# echo x > a
    root@MediaStore:/mnt/user/Downloads# chmod 600 a
    root@MediaStore:/mnt/user/Downloads# ls -l a
    -rw------- 1 root root 2 Mar 23 21:44 a
    root@MediaStore:/mnt/user/Downloads# ls -l /mnt/cache/Downloads/a
    -rw------- 1 root root 2 Mar 23 21:44 /mnt/cache/Downloads/a
    root@MediaStore:/mnt/user/Downloads# cat a
    root@MediaStore:/mnt/user/Downloads# su nobody -s /bin/sh
    nobody@MediaStore:/mnt/user/Downloads$ cat a
    nobody@MediaStore:/mnt/user/Downloads$ cat /mnt/cache/Downloads/a
    cat: /mnt/cache/Downloads/a: Permission denied
    nobody@MediaStore:/mnt/user/Downloads$ echo y > a
    nobody@MediaStore:/mnt/user/Downloads$ cat a


    I hope this is not directly caused by Limetech's stance that Unraid is an appliance and should only have the root user.

    As this can cause breakage with NFS shares, ransomware protection and general stuff and use cases that expect file permissions to protect stuff

    • Like 1
    • Thanks 1
  4. I just retested with 6.9.0 and the same issue still exists

    root@MediaStore:~# docker run --rm --name box -d -v /mnt/cache/Downloads:/media alpine sleep 3600
    root@MediaStore:~# docker exec -u 1002 -it box sh -c 'id; ls -ld /media; touch /media/a_file && ls -l /media/a_file'
    uid=1002 gid=0(root)
    drwxrws---    1 99       users       245858 Mar  7 23:56 /media
    touch: /media/a_file: Permission denied
    root@MediaStore:~# docker stop box
    root@MediaStore:~# docker run --rm --name box -d -v /mnt/user/Downloads:/media alpine sleep 3600
    root@MediaStore:~# docker exec -u 1002 -it box sh -c 'id; ls -ld /media; touch /media/a_file && ls -l /media/a_file && rm -v /media/a_file'
    uid=1002 gid=0(root)
    drwxrws---    1 99       users       245858 Mar  8 14:03 /media
    -rw-r--r--    1 1002     root             0 Mar  8 14:04 /media/a_file
    removed '/media/a_file'


    • Like 1
  5. On 2/24/2021 at 1:01 AM, jbartlett said:

    I doubt they'd be considering putting Slackware 15.0 in the UNRAID OS until it's released as stable, it's not even in the beta phase yet.


    We're actually on Slackware-current already - so we've been on Slackware 15.0 - pre-alpha for a while now.

    ### Version 6.8.0 2019-12-10
    Base distro:
    - aaa_elflibs: version 15.0 build 16


    • Like 1
  6. 6 hours ago, TechGeek01 said:

    This is an issue on RC1. I have not tested on RC2, since my networking setup has since changed, but if you didn't know about this, it probably applies to RC2 as well.


    Firstly, if we're enabling VLANs, and put an IP on a VLAN, but don't want an IP on the whole untagged interface, there probably should be an option for "no IP" rather than just letting "automatic" give it a 169 address. It's a minor annoyance that leads to the 169 address showing in the top right corner, as opposed to the real, set IP in the VLAN interface.


    The problem this creates is that in this scenario, where there's an auto 169 address on the untagged interface, and the "real" accessible web UI IP on a tagged VLAN on the same interface, installing things like plugins fails, because the 169 address has no internet connection, so Unraid can't connect to the internet.


    My guess is the best way to handle that would be to try the next IP in line on a VLAN should the main interface IP fail to resolve internet, until it hits one that works, instead of just giving up after the first fail. And/or let us "disable" IP assignment on an interface, or subinterface, so that instead of trying the untagged VLAN on a port, it knows to skip it, and use the tagged VLAN IP instead.

    This is exactly how networking works. When any process decides to access something, the network stack consults the routing table and determines what interface and router to use. If your untagged interface (regardless of IP) does not have a gateway defined then it will not get used to reach the internet. A lot of times before people had multiple VLANs with gateways configured (statically or dhcp), this would make it so the lastest interface to come up and be added to routing table would get used as the internet connection - even if the last interface to come up doesn't have a working internet.


    I suppose a missing feature of unraid is the ability for us to define/tweak the desired table, including overrides for DHCP enabled interfaces and other suck configurations.


  7. That's my actual solution to the situation as it guarantees the correct permissions on the OS layer. But I understand you can't turn that on users with older data and managed permissions. I'm guessing this can be a Unraid setting, but users should opt-in, unless its a brand new OS config.


    FYI a lot of NAS use something like that setting to make it easy for the files to be managed, even after migrating the disks out to another OS.

  8. Quick peek at your diags show your network config is bonkered

    you have 3 network interfaces with the same IP address and gateway assigned to all of them. In this case, nobody can predict the networking to be functional as the routing table would make no sense.

    you network config actually declares an eth4/br4 - but that interface doesn't exist.

    Quick fix. Shut down UnRAID, and pull the USB. Edit file config/network.cfg

    # Generated settings:

    This should be doable in the GUI with the GUI boot mode using the local browser, but I've never used GUI boot mode.

    • Upvote 1
  9. Running a plain jane LSI SAS9206-16e - ran stable without any issues since 6beta.


    Hmmm - guess if it works you don't really need to flash...

    mpt2sas_cm0: LSISAS2308: FWVersion(, ChipRevision(0x05), BiosVersion(


  10. On 9/2/2018 at 5:01 PM, Ordspilleren said:

    AFAIK, the solution here is to not use the physical network interface directly. Simply create a macvlan interface for the host to use, just like with the dockers. This enables communication between host and containers. Might be something to consider.

    I've been meaning to try this... gotta find time while I'm around as recovery can be really ugly if doing it remotely without IPMI or similar features.

  11. 1 hour ago, alturismo said:

    and is it now possible to give dockers their own IP´s without isolating them from the host network ?

    Unless something changes with the Linux kernel or the docker engine, this isn't going to happen. Maybe if we had the ipvlan drivers... but this has its own caveats and is not yet in prime time AFAIK.