[Unraid OS version 6.10.0-rc1 available]

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.

 

[[6.9.2] No connection br0 -> bridge]

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:

 

 

[[6.8.3] [6.9.0] [6.9.1] shfs seems to ignore permissions]

Changed Status to Solved

[[6.8.3] [6.9.0] [6.9.1] shfs seems to ignore permissions]

This seems to have fixed the issue.

[[6.8.3] [6.9.0] [6.9.1] shfs seems to ignore permissions]

@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
x
root@MediaStore:/mnt/user/Downloads# su nobody -s /bin/sh
nobody@MediaStore:/mnt/user/Downloads$ cat a
x
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
y

 

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

[[6.9.0] /etc/profile.d changes are breaking ability to spawn shells in certain directories]

I'm simply running multiple root shells under tmux with each shell in its own directory. I think that's a fair use of unraid, without going into the whole other users can of worms.

 

So you can imagine my surprise when a simple login shell refused to open in the specific directory I had it open.

 

 

[[6.9.0] /etc/profile.d changes are breaking ability to spawn shells in certain directories]

Nothing that I have noticed. So it should be safe to revert in the next version. 😛

[[6.8.3] [6.9.0] [6.9.1] shfs seems to ignore permissions]

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
520f6d86f848a8558c1ac66f01107f0c02b63bad8481af71491aee5523000b0b
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
box
root@MediaStore:~# docker run --rm --name box -d -v /mnt/user/Downloads:/media alpine sleep 3600
4c5815e3e8d5b43c0d6b667dcf88cea7eb2d6b842a67125c606660c0613d22fe
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'

 

[Unraid OS version 6.9.0-rc2 available]

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

 

[[6.8.3] [6.9.0] [6.9.1] shfs seems to ignore permissions]

@limetech Any thoughts?

[Changing Port Numbers]

Your going to have to provide examples/screenshots and probably logs regarding this bug report as anybody trying to replicate this would just ignore it as there's nothing in here to follow

[Unraid OS version 6.9.0-rc2 available]

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.

 

[[6.8.0] File permissions through Samba are set to admin:users and not nobody:users]

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.

[No network connection]

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:
IFNAME[0]="eth0"
PROTOCOL[0]="ipv4"
USE_DHCP[0]="no"
IPADDR[0]="192.168.1.22"
NETMASK[0]="255.255.255.0"
GATEWAY[0]="192.168.1.1"
DNS_SERVER1="192.168.1.1"
USE_DHCP6[0]="yes"
DHCP6_KEEPRESOLV="no"
MTU[0]="1500"
SYSNICS="1"

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

[SECURITY SETTINGS cron not work]

Have you tried following this in the NFS rules?

 

[Please allow to disable automatic parity check on "unclean shutdown"]

and google won't let a device use a reserved IP unless the mac address matches?

[Please allow to disable automatic parity check on "unclean shutdown"]

And you can't just assign a static IP to Unraid and be done with it?

[Please allow to disable automatic parity check on "unclean shutdown"]

7 hours ago, nuhll said:

if i had any normal netowrk solution this would be no problem, but since my whole network get managed by google wifi, all is sh1t.

 

I would need to reasing the 2 ip addresses and manual add all port forwardings again. (via app)

Not a google wifi user so i don't know how hard/annoying assigning a static IP can be.

[Please allow to disable automatic parity check on "unclean shutdown"]

Is there any real reason why you cannot use the real mac address of the board?

I personally think using a made-up / copied mac address is only for transitions or workaround to licensing

[[6.6.7] Spammy erros, missing vm's, share issue.]

Very quickly (and without checking diagnostics) I'd say your USB drive dropped offline (and came back on) - or the USB port was reset.

[Unraid-Server login[3651]: ILLEGAL ROOT LOGIN on '/dev/pts/8']

Just wondering... if it would be better to just use '/bin/bash -l' vs 'login -f root' as the ttyd terminal?

[custom docker network does not allow entering container port in mapping]

Seems like the UI doesn't fully support the custom bridge network yet. (Haven't had a use case for it myself)

[6.6.0-6.6.1 LSI 9211-8i Issues]

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(17.00.01.00), ChipRevision(0x05), BiosVersion(07.33.00.00)

 

[Unraid OS version 6.6.0-rc1 available]

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.

[Unraid OS version 6.6.0-rc1 available]

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.