ati

I used the 'create dataset' button in ZFS master to create a folder/dataset (at the top level). Later I noticed that unRAID created a share matching that dataset name and assigned it the incorrect primary storage. It didn't seem to matter what unRAID did, the folder/dataset (and it's data) still only existed on the ZFS pool, but it was a but interesting to see that unRAID assigned the BTRFS pool as the primary share for it. Thanks for the info. It is good to know that is 'normal'. I was mostly playing with ZFS at this point trying to get the feel for how I wanted to use it before moving all my data to the new ZFS cache pool.

Just wondering if this is normal expected behavior. I have 2 cache pools: 2 drive BTRFS pool (called cache) 2 drive ZFS pool (called nvmecache) I used the ZFS master plugin to make a new testing dataset on the root of my nvmecache (/mnt/nvmecache/testdataset) The data set was made and all appeared normal, however, if I go into the shares tab on the unRAID GUI I have a new share. It is called testdataset and it is set to use my cache pool, not the nvmecache pool. Is it normal for it to create a share like that? Especially using the wrong pool?

I am going on a adventure to try and better harden my containers and better isolate them from one another as well as the host server itself. I use IPVLAN and isolate my containers into VLANs based on 'activities'. For example: *arr stack is one VLAN, personal utilities (paperless or trillium notes is another VLAN, etc. First question: Why can I not add VLANs to unRAID without having an IP address associated with it? The unRAID server itself doesn't need to have any presence on the VLAN for my *arr stack for example. The containers in the stack are isolated and firewalled off so I can only access them via a reverse proxy, but because unRAID puts an interface in that VLAN there are no firewall rules to stop it as it is layer 2. It seems like the docker engine 'blocks it' by I am not sure at what level it is blocked. Are there any other best practices for host isolation? I have host access to custom networks disabled in my Docker settings. I don't have a single container that I run that should ever need access to unRAID directly, and I want to be sure it is 100% blocked otherwise. I only run containers in br0.x on VLANs outside if the native VLAN for unRAID itself, so that should help as well. Is it better to use custom docker networks, or use external VLANs for containers? I am much more comfortable using my external router/firewall, but if there is an inherent advantage to using Docker custom networks I can go that route as well. I recently learned that Docker uses the DNS settings of the host by default, so I am also in the process of adding the --dns=x.x.x.x to all the containers that I don't wish to use my internal DNS server. Looking for feedback, best practices and opinions on how to better harden my system and containers. There is a lot of trust in the FOSS community where we blindly trust run containers. As vibe coding becomes more and more common (thinking a bit about the Huntarr fiasco) I think a little hardening is a good idea.

I have been running my binhex-flaresolverr behind my binhex-delugevpn container for some time. Just recently I noticed that it is failing to work with Prowler (also running via binhex-delugevpn). It results in a connection refused every time. If I move the binhex-flaresolverr out from behind the binhex-delugevpn it works fine. I am a bit lost as to how to troubleshoot this as there isn't any useful logging showing why it fails.an I can curl flaresolverr from my Prowlarr container just fine: sh-5.3# curl http://192.168.xx.xx:8191 {"msg": "FlareSolverr is ready!", "version": "3.4.6", "userAgent": "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36"}sh-5.3#

Does anyone else have issues with the WebUI for this container working? It is the only container I seem to constantly have to restart and fiddle with to get the WebUI to work. The logging shows nothing either. Same issue across several versions.

I currently have a Supermicro 826 that I got used with the motherboard, CPU and RAM many moons ago and it is time to upgrade. I would like to build my own server (motherboard/CPU/RAM) vs, getting one with used components. As a result it would be much easier in a 3U or 4U case as those will support commodity hardware/coolers better. I really want a full depth case with rails, not a shallow screw mount rack case. I also would like to have more than my current 12 hot sway bays. 16+ would be ideal. Any recommendations for cases? Preferably used. The Supermicro 836 comes up a lot on forums, but I want to consider all options. SIDE NOTE: This would be my first go a 'rolling my own' in a server chassis. Any concerns with consumer CPU coolers in a 3U case?

Well this ended up breaker my entire docker image and freezing my server. I believe it is a result of some type of network conflict. Similar to here: https://forums.unraid.net/topic/181342-docker-engine-freeze-locks-up-unraid/ Not really sure how to do this correctly now...

Well I got it to work once making a custom internal network, now I get this error after I try to start the stack again: Error response from daemon: driver failed programming external connectivity on endpoint immich_server (04565a5b1f19222fe7a7245130294e2f27b8b6fe6c51dc81b6fd7bbc36b00da0): Error starting userland proxy: listen tcp4 192.168.10.137:2283: bind: cannot assign requested address

I am still running into issues. I am trying, to start, to just run the Immich server on my main VLAN which is br0 and leave all the other Immich containers on their default network. So I have this in my otherwise default from Immich compose file. (from here: https://github.com/immich-app/immich/releases/tag/v2.4.1) name: immich services: immich-server: ... ports: - 192.168.10.137:2283:2283 ... networks: br0: ipv4_address: 192.168.10.137However, when I do this, the sever will not start. Presumably there is a missing link between my br0 network and the default Immich compose network? How do I set the main server to have 2 interfaces? The network the other containers use is 'immich_default', but I see no reference to that in the compose file, so how do I add that as a network for the immich_server docker? Whenever I do try and add it, it says it is not defined in the compose messages when starting the stack.

I have not, but I didn't think it applies? If you look at the help it is for macvlans, but I am using ipvlans. Regardless, it looks like it could be the issue and the help is just incorrect?

I am running Nginx Proxy Manager via a Br0.80 interface. So it is running on VLAN 80, with an IP address of 192.168.80.50. It is all setup a working great for several other Br0.80 services, as VLAN 80 is my DMZ. I am trying to setup a few 'LAN only' proxies so I can access local resources using domain names instead of IP addresses. I was able to add several other Br0.VLAN services just fine. However the issue is any service that is running in bridge mode (using the same IP address as my unRAID server) will not work. I cannot even curl the sites from the Nginx Proxy Manager. It seems like something in the unRAID docker engine is blocking me from being able to access the unRAID host IP address.

I am an absolute idiot when it comes to compose files, this is my first try at one. I am trying to run Immich (which I have working via this guide), but I want to set it to run on a separate IP instead of the bridged IP with my unRAID server. My unRAID server is 192.168.10.40, and by default Immich runs at 192.168.10.40:2283. I want to edit the compose file to run the Immich server (or stack?) via br0 on a different network. All my dockers that I allow external access to are on a different VLAN, so I would like Immich do exist on that VLAN as well. How do I modify my compose file to do this? name: immich services: immich-server: container_name: immich_server image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release} # extends: # file: hwaccel.transcoding.yml # service: cpu # set to one of [nvenc, quicksync, rkmpp, vaapi, vaapi-wsl] for accelerated transcoding volumes: # Do not edit the next line. If you want to change the media storage location on your system, edit the value of UPLOAD_LOCATION in the .env file - ${UPLOAD_LOCATION}:/data - /etc/localtime:/etc/localtime:ro - ${PHONE_PHOTOS}:/home/user/PhonePhotos:ro env_file: - .env ports: - '2283:2283' depends_on: - redis - database restart: always healthcheck: disable: false immich-machine-learning: container_name: immich_machine_learning # For hardware acceleration, add one of -[armnn, cuda, rocm, openvino, rknn] to the image tag. # Example tag: ${IMMICH_VERSION:-release}-cuda image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release} # extends: # uncomment this section for hardware acceleration - see https://docs.immich.app/features/ml-hardware-acceleration # file: hwaccel.ml.yml # service: cpu # set to one of [armnn, cuda, rocm, openvino, openvino-wsl, rknn] for accelerated inference - use the -wsl version for WSL2 where applicable volumes: - model-cache:/cache env_file: - .env restart: always healthcheck: disable: false redis: container_name: immich_redis image: docker.io/valkey/valkey:8@sha256:81db6d39e1bba3b3ff32bd3a1b19a6d69690f94a3954ec131277b9a26b95b3aa healthcheck: test: redis-cli ping || exit 1 restart: always database: container_name: immich_postgres image: ghcr.io/immich-app/postgres:14-vectorchord0.4.3-pgvectors0.2.0@sha256:bcf63357191b76a916ae5eb93464d65c07511da41e3bf7a8416db519b40b1c23 environment: POSTGRES_PASSWORD: ${DB_PASSWORD} POSTGRES_USER: ${DB_USERNAME} POSTGRES_DB: ${DB_DATABASE_NAME} POSTGRES_INITDB_ARGS: '--data-checksums' # Uncomment the DB_STORAGE_TYPE: 'HDD' var if your database isn't stored on SSDs # DB_STORAGE_TYPE: 'HDD' volumes: # Do not edit the next line. If you want to change the database storage location on your system, edit the value of DB_DATA_LOCATION in the .env file - ${DB_DATA_LOCATION}:/var/lib/postgresql/data shm_size: 128mb restart: always volumes: model-cache:

I recently noticed some odd port assignments shown on my main docker page for containers that route their network via another container. Here is a quick example where my Jackett container routes via my Deluge VPN container, which is 192.168.70.xx, and when I access Jackett it is 192.168.70.xx:jackett_port as expected. So, why is jackett showing mappings for 192.168.90.xx a subnet that isn't part of the equation here. I think long before I moved to running Jackett via deluge it was on that subnet, but I guess I never really noticed that they haven't 'gone away' after the change.

I got an email from LetsEncrypt that two of my domains had certificates that were going to expire in 10 days. In the last few years I haven't thought twice about it as NPM just took care of it. I went into the GUI and tried to manually renew the certs and got "Internal Error". I decided to reboot the docker and now it won't boot at all. This is in the log over and over again: ❯ Starting nginx ... nginx: [warn] the "listen ... http2" directive is deprecated, use the "http2" directive instead in /data/nginx/proxy_host/3.conf:14 nginx: [warn] the "listen ... http2" directive is deprecated, use the "http2" directive instead in /data/nginx/proxy_host/3.conf:15 nginx: [warn] the "listen ... http2" directive is deprecated, use the "http2" directive instead in /data/nginx/proxy_host/7.conf:14 nginx: [warn] protocol options redefined for 0.0.0.0:443 in /data/nginx/proxy_host/7.conf:14 nginx: [warn] the "listen ... http2" directive is deprecated, use the "http2" directive instead in /data/nginx/proxy_host/7.conf:15 nginx: [warn] protocol options redefined for [::]:443 in /data/nginx/proxy_host/7.conf:15 nginx: [warn] the "listen ... http2" directive is deprecated, use the "http2" directive instead in /data/nginx/redirection_host/3.conf:10 nginx: [warn] the "listen ... http2" directive is deprecated, use the "http2" directive instead in /data/nginx/redirection_host/3.conf:11 nginx: [emerg] cannot load certificate "/etc/letsencrypt/live/npm-5/fullchain.pem": BIO_new_file() failed (SSL: error:80000002:system library::No such file or directory:calling fopen(/etc/letsencrypt/live/npm-5/fullchain.pem, r) error:10000080:BIO routines::no such file) What happened here, and how can I resolve it? Looks like something with a keyfile has failed?

Just for my own knowledge, how can you tell? I didn't see anything about it 'forcing' an unmount or anything in the log. I saw that was a common solution/problem when searching this, but I couldn't see any signs in the log.

I had large storms in the area on Monday (8/26 around 19:11) and lost power, my UPS supported the load and iniciated a shutdown of my unRAID server as expected (I think). I recently got power back and begain restarting my server, but once it was up I noticed I got an unclean shutdown error for the array. I dug into the logs and I cannot find anything jumping out to me as to why it might belive it was an unclean shutdown. And yes, incase anyone is wondering, I have my UPS shutdown level set very high. I don't often get power blips lasting longer than 5-10 seconds. If the power is out more then 30 seconds, it isn't coming back soon. So in an effort to save my batteries I shutdown early. Log attached. syslog-previous_truncated.txt

This is a great start. Thank you!

I generally don't shutdown or stop the array on my unRAID server. I was doing some electrical work in the house this past week and this was the first time I have shutdown my server in some time. I learned I was susceptible to the "Retry unmounting disk share(s)" issue even though I am running on 6.11.5. I run my server on a UPS and have it set to auto shutdown after a 3 minute outage. I always assumed that it would properly shutdown, but I guess not (crazy me assuming things). So for the past 6+ months I have been basically susceptible to an 'unclean' shutdown. Is there any way to force a clean shutdown? Frankly I have very little interest in updating to 6.12.3. I am slowly losing trust in LimeTech to QA/QC any update. The last time I updated I had to rebuild disks due to the Seagate error. While I understand that wasn't all on LimeTech, issuing a 'stable' release that fails to shutdown is pretty crazy. Furthermore, there are still reports of it not being fixed in 6.12.3. I have no interest in beta testing for development, that is why I generally stay a revision behind.

I am hoping someone can give my some guidance on getting Paperless-NGX to work with Nginx Proxy Manager. It works fine when I assign both Redis and Paperless-NGX a br0 address on my LAN. However, when I used a bridge address it does not work. I get an 502 error. This is for local access only. I run an instance of NPM for all my services where the names are *.local (unraid.local, plex.local) etc. PiHole for DNS resolution to point to the NPM server. I generally prefer to setup custom Docker networks for services like this for the redis link, but I cannot seem to get the proxy to work without having both dockers having their own LAN IP.

I want to have BR0 and BR0.10 going to a single container. Either 2 interfaces each on their own VLAN or a single interface that can support trunking.

I have a user created that uses SSH to copy files to a public share on my server. I was using this as a means to copy pictures from my phone to server automatically every night. After the update this now fails with permission denied on copy. I also tried using the same credentials on my windows machine with WinSCP and got the same error. Seems to work fine when I log in as root. user and group of the folder is nobody:nobody as well.

I would like to move my UniFI AP controller into a docker container on my unRAID server. My unRAID server is already configured for VLANs and has the appropriate VLANs accessible to its BR0 interface. What I am not sure about is how to get a trunk port to my UniFI controller's docker container. Current network setup: VLAN 1: Network management VLAN 10: Servers VLAN 20: Wireless clients VLAN 40: IoT clients While everything is routable, I would prefer to not have to route my AP management traffic (VLAN 1) to my UniFI server (VLAN 10). Makes everything more complicated when adopting new equipment. TL;DR How can I pass multiple VLANs to a docker container?

I recently went the route of adding several VLANs to segment my docker containers into DMZ areas. In the process I noticed that you have to have an IP address set in the network settings for the network (VLAN) to be available to Docker. I guess that makes sense, as that is how they learn a default gateway. However, that poses a security risk in my mind. If one of those containers gets compromised, it can access the unRAID server which now has an IP on that network. Is there anyway I can disable the GUI and SSH access from a specific interface? Because it is on the same network segment, a router firewall rule is useless.

Tried that many times. Tried each port individually even. When I deleted the /config/network.cfg I set it back up as a single interface. After lots of reboots (to remove the USB and get diagnostic files off it) it just worked after no changes. Any idea where there are lots of references in the syslog to virbr0 using an IP address that isn't anywhere on my network or unRAID configuration? Regardless, I am afraid to reboot for fear of having this ordeal happen again. I spent 3 hours rebooting my server in circles for it to miraculously work again using the same configuration I started with 3 hours prior.

I am even more lost now. I shut down, to get the diagnostics off the USB and upon reboot it booted normally and I was able to access it via the network. I logged into the web GUI to startup the array. Hell I even got an email alert that my UPS was unplugged (to get the USB out). About 30 seconds into starting the array I lost network again. I connected back to the server to checkout the syslog and saw this: Mar 7 15:14:38 unRAID root: Starting diskload Mar 7 15:14:38 unRAID emhttpd: Mounting disks... Mar 7 15:14:38 unRAID emhttpd: shcmd (197): /sbin/btrfs device scan Mar 7 15:14:38 unRAID root: Scanning for Btrfs filesystems Mar 7 15:14:38 unRAID emhttpd: shcmd (198): mkdir -p /mnt/disk1 Mar 7 15:14:38 unRAID emhttpd: shcmd (199): mount -t xfs -o noatime,nodiratime /dev/md1 /mnt/disk1 Mar 7 15:14:38 unRAID kernel: SGI XFS with ACLs, security attributes, no debug enabled Mar 7 15:14:38 unRAID kernel: XFS (md1): Mounting V5 Filesystem Mar 7 15:14:38 unRAID kernel: XFS (md1): Ending clean mount Mar 7 15:14:38 unRAID emhttpd: shcmd (200): xfs_growfs /mnt/disk1 Mar 7 15:14:38 unRAID root: meta-data=/dev/md1 isize=512 agcount=8, agsize=244188659 blks Mar 7 15:14:38 unRAID root: = sectsz=512 attr=2, projid32bit=1 Mar 7 15:14:38 unRAID root: = crc=1 finobt=1, sparse=1, rmapbt=0 Mar 7 15:14:38 unRAID root: = reflink=1 Mar 7 15:14:38 unRAID root: data = bsize=4096 blocks=1953506633, imaxpct=5 Mar 7 15:14:38 unRAID root: = sunit=0 swidth=0 blks Mar 7 15:14:38 unRAID root: naming =version 2 bsize=4096 ascii-ci=0, ftype=1 Mar 7 15:14:38 unRAID root: log =internal log bsize=4096 blocks=476930, version=2 Mar 7 15:14:38 unRAID root: = sectsz=512 sunit=0 blks, lazy-count=1 Mar 7 15:14:38 unRAID root: realtime =none extsz=4096 blocks=0, rtextents=0 Mar 7 15:14:38 unRAID emhttpd: shcmd (201): mkdir -p /mnt/disk2 Mar 7 15:14:38 unRAID emhttpd: shcmd (202): mount -t xfs -o noatime,nodiratime /dev/md2 /mnt/disk2 Mar 7 15:14:38 unRAID kernel: XFS (md2): Mounting V5 Filesystem Mar 7 15:14:38 unRAID kernel: XFS (md2): Ending clean mount Mar 7 15:14:38 unRAID emhttpd: shcmd (203): xfs_growfs /mnt/disk2 Mar 7 15:14:38 unRAID root: meta-data=/dev/md2 isize=512 agcount=8, agsize=244188659 blks Mar 7 15:14:38 unRAID root: = sectsz=512 attr=2, projid32bit=1 Mar 7 15:14:38 unRAID root: = crc=1 finobt=1, sparse=1, rmapbt=0 Mar 7 15:14:38 unRAID root: = reflink=1 Mar 7 15:14:38 unRAID root: data = bsize=4096 blocks=1953506633, imaxpct=5 Mar 7 15:14:38 unRAID root: = sunit=0 swidth=0 blks Mar 7 15:14:38 unRAID root: naming =version 2 bsize=4096 ascii-ci=0, ftype=1 Mar 7 15:14:38 unRAID root: log =internal log bsize=4096 blocks=476930, version=2 Mar 7 15:14:38 unRAID root: = sectsz=512 sunit=0 blks, lazy-count=1 Mar 7 15:14:38 unRAID root: realtime =none extsz=4096 blocks=0, rtextents=0 Mar 7 15:14:38 unRAID emhttpd: shcmd (204): mkdir -p /mnt/disk3 Mar 7 15:14:38 unRAID emhttpd: shcmd (205): mount -t xfs -o noatime,nodiratime /dev/md3 /mnt/disk3 Mar 7 15:14:38 unRAID kernel: XFS (md3): Mounting V5 Filesystem Mar 7 15:14:39 unRAID kernel: XFS (md3): Ending clean mount Mar 7 15:14:39 unRAID emhttpd: shcmd (206): xfs_growfs /mnt/disk3 Mar 7 15:14:39 unRAID root: meta-data=/dev/md3 isize=512 agcount=6, agsize=268435455 blks Mar 7 15:14:39 unRAID root: = sectsz=512 attr=2, projid32bit=1 Mar 7 15:14:39 unRAID root: = crc=1 finobt=1, sparse=1, rmapbt=0 Mar 7 15:14:39 unRAID root: = reflink=1 Mar 7 15:14:39 unRAID root: data = bsize=4096 blocks=1465122442, imaxpct=5 Mar 7 15:14:39 unRAID root: = sunit=0 swidth=0 blks Mar 7 15:14:39 unRAID root: naming =version 2 bsize=4096 ascii-ci=0, ftype=1 Mar 7 15:14:39 unRAID root: log =internal log bsize=4096 blocks=521728, version=2 Mar 7 15:14:39 unRAID root: = sectsz=512 sunit=0 blks, lazy-count=1 Mar 7 15:14:39 unRAID root: realtime =none extsz=4096 blocks=0, rtextents=0 Mar 7 15:14:39 unRAID emhttpd: shcmd (207): mkdir -p /mnt/cache Mar 7 15:14:39 unRAID emhttpd: cache uuid: 7cb7e73a-56e0-4226-b453-ed9ec86cc38f Mar 7 15:14:39 unRAID emhttpd: cache TotDevices: 2 Mar 7 15:14:39 unRAID emhttpd: cache NumDevices: 2 Mar 7 15:14:39 unRAID emhttpd: cache NumFound: 2 Mar 7 15:14:39 unRAID emhttpd: cache NumMissing: 0 Mar 7 15:14:39 unRAID emhttpd: cache NumMisplaced: 0 Mar 7 15:14:39 unRAID emhttpd: cache NumExtra: 0 Mar 7 15:14:39 unRAID emhttpd: cache LuksState: 0 Mar 7 15:14:39 unRAID emhttpd: shcmd (208): mount -t btrfs -o noatime,nodiratime -U 7cb7e73a-56e0-4226-b453-ed9ec86cc38f /mnt/cache Mar 7 15:14:39 unRAID kernel: BTRFS info (device sdh1): using free space tree Mar 7 15:14:39 unRAID kernel: BTRFS info (device sdh1): has skinny extents Mar 7 15:14:56 unRAID emhttpd: shcmd (209): /sbin/btrfs filesystem resize 1:max /mnt/cache Mar 7 15:14:56 unRAID root: Resize '/mnt/cache' of '1:max' Mar 7 15:14:56 unRAID kernel: BTRFS info (device sdh1): resizing devid 1 Mar 7 15:14:56 unRAID kernel: BTRFS info (device sdh1): new size for /dev/sdh1 is 3000592928768 Mar 7 15:14:56 unRAID emhttpd: shcmd (210): /sbin/btrfs filesystem resize 2:max /mnt/cache Mar 7 15:14:56 unRAID root: Resize '/mnt/cache' of '2:max' Mar 7 15:14:56 unRAID kernel: BTRFS info (device sdh1): resizing devid 2 Mar 7 15:14:56 unRAID kernel: BTRFS info (device sdh1): new size for /dev/sde1 is 3000592928768 Mar 7 15:14:56 unRAID emhttpd: shcmd (211): sync Mar 7 15:14:56 unRAID emhttpd: shcmd (212): mkdir /mnt/user0 Mar 7 15:14:56 unRAID emhttpd: shcmd (213): /usr/local/sbin/shfs /mnt/user0 -disks 14 -o noatime,allow_other |& logger Mar 7 15:14:56 unRAID shfs: use_ino: 1 Mar 7 15:14:56 unRAID shfs: direct_io: 0 Mar 7 15:14:56 unRAID emhttpd: shcmd (214): mkdir /mnt/user Mar 7 15:14:56 unRAID emhttpd: shcmd (215): /usr/local/sbin/shfs /mnt/user -disks 15 2048000000 -o noatime,allow_other -o remember=0 |& logger Mar 7 15:14:56 unRAID shfs: use_ino: 1 Mar 7 15:14:56 unRAID shfs: direct_io: 0 Mar 7 15:14:57 unRAID emhttpd: shcmd (217): /usr/local/sbin/update_cron Mar 7 15:14:57 unRAID root: Delaying execution of fix common problems scan for 10 minutes Mar 7 15:14:57 unRAID unassigned.devices: Mounting 'Auto Mount' Devices... Mar 7 15:14:57 unRAID emhttpd: Starting services... Mar 7 15:14:57 unRAID emhttpd: shcmd (220): /etc/rc.d/rc.samba restart Mar 7 15:14:59 unRAID root: Starting Samba: /usr/sbin/smbd -D Mar 7 15:15:00 unRAID root: /usr/sbin/nmbd -D Mar 7 15:15:00 unRAID root: /usr/sbin/wsdd Mar 7 15:15:00 unRAID root: /usr/sbin/winbindd -D Mar 7 15:15:00 unRAID emhttpd: shcmd (234): /usr/local/sbin/mount_image '/mnt/cache/system/docker/docker.img' /var/lib/docker 40 Mar 7 15:15:00 unRAID kernel: BTRFS: device fsid 1e042287-9021-48d2-8ad1-772169654339 devid 1 transid 1747553 /dev/loop2 Mar 7 15:15:00 unRAID kernel: BTRFS info (device loop2): using free space tree Mar 7 15:15:00 unRAID kernel: BTRFS info (device loop2): has skinny extents Mar 7 15:15:00 unRAID root: Resize '/var/lib/docker' of 'max' Mar 7 15:15:00 unRAID kernel: BTRFS info (device loop2): new size for /dev/loop2 is 42949672960 Mar 7 15:15:00 unRAID emhttpd: shcmd (236): /etc/rc.d/rc.docker start Mar 7 15:15:00 unRAID root: starting dockerd ... Mar 7 15:15:04 unRAID avahi-daemon[10987]: Joining mDNS multicast group on interface br-4ead1d45ff54.IPv4 with address 172.18.0.1. Mar 7 15:15:04 unRAID avahi-daemon[10987]: New relevant interface br-4ead1d45ff54.IPv4 for mDNS. Mar 7 15:15:04 unRAID avahi-daemon[10987]: Registering new address record for 172.18.0.1 on br-4ead1d45ff54.IPv4. Mar 7 15:15:04 unRAID kernel: IPv6: ADDRCONF(NETDEV_UP): br-4ead1d45ff54: link is not ready Mar 7 15:15:04 unRAID avahi-daemon[10987]: Joining mDNS multicast group on interface br-66b05052a9b2.IPv4 with address 192.168.240.1. Mar 7 15:15:04 unRAID avahi-daemon[10987]: New relevant interface br-66b05052a9b2.IPv4 for mDNS. Mar 7 15:15:04 unRAID avahi-daemon[10987]: Registering new address record for 192.168.240.1 on br-66b05052a9b2.IPv4. Mar 7 15:15:04 unRAID kernel: IPv6: ADDRCONF(NETDEV_UP): br-66b05052a9b2: link is not ready Mar 7 15:15:04 unRAID avahi-daemon[10987]: Joining mDNS multicast group on interface docker0.IPv4 with address 172.17.0.1. Mar 7 15:15:04 unRAID avahi-daemon[10987]: New relevant interface docker0.IPv4 for mDNS. Mar 7 15:15:04 unRAID avahi-daemon[10987]: Registering new address record for 172.17.0.1 on docker0.IPv4. Mar 7 15:15:04 unRAID kernel: IPv6: ADDRCONF(NETDEV_UP): docker0: link is not ready Mar 7 15:15:09 unRAID rc.docker: b1f70fe360063b35c8f89ccb8a5befd5f30feb5c090801074f6f4ddcbd41b28f Mar 7 15:15:11 unRAID emhttpd: shcmd (250): /usr/local/sbin/mount_image '/mnt/cache/system/libvirt/libvirt.img' /etc/libvirt 1 Mar 7 15:15:11 unRAID kernel: BTRFS: device fsid bc304288-554a-4fd8-a63c-b4a0a37f5e68 devid 1 transid 262 /dev/loop3 Mar 7 15:15:11 unRAID kernel: BTRFS info (device loop3): using free space tree Mar 7 15:15:11 unRAID kernel: BTRFS info (device loop3): has skinny extents Mar 7 15:15:11 unRAID root: Resize '/etc/libvirt' of 'max' Mar 7 15:15:11 unRAID kernel: BTRFS info (device loop3): new size for /dev/loop3 is 1073741824 Mar 7 15:15:11 unRAID emhttpd: shcmd (252): /etc/rc.d/rc.libvirt start Mar 7 15:15:11 unRAID root: Starting virtlockd... Mar 7 15:15:11 unRAID root: Starting virtlogd... Mar 7 15:15:11 unRAID root: Starting libvirtd... Mar 7 15:15:11 unRAID kernel: tun: Universal TUN/TAP device driver, 1.6 Mar 7 15:15:11 unRAID kernel: virbr0: port 1(virbr0-nic) entered blocking state Mar 7 15:15:11 unRAID kernel: virbr0: port 1(virbr0-nic) entered disabled state Mar 7 15:15:11 unRAID kernel: device virbr0-nic entered promiscuous mode Mar 7 15:15:11 unRAID emhttpd: nothing to sync Mar 7 15:15:11 unRAID kernel: bond0: link status definitely down for interface eth0, disabling it Mar 7 15:15:11 unRAID kernel: bond0: making interface eth1 the new active one Mar 7 15:15:11 unRAID kernel: device eth0 left promiscuous mode Mar 7 15:15:11 unRAID kernel: device eth1 entered promiscuous mode Mar 7 15:15:11 unRAID avahi-daemon[10987]: Joining mDNS multicast group on interface virbr0.IPv4 with address 192.168.122.1. Mar 7 15:15:11 unRAID avahi-daemon[10987]: New relevant interface virbr0.IPv4 for mDNS. Mar 7 15:15:11 unRAID avahi-daemon[10987]: Registering new address record for 192.168.122.1 on virbr0.IPv4. Mar 7 15:15:11 unRAID kernel: virbr0: port 1(virbr0-nic) entered blocking state Mar 7 15:15:11 unRAID kernel: virbr0: port 1(virbr0-nic) entered listening state Mar 7 15:15:11 unRAID dnsmasq[14786]: started, version 2.80 cachesize 150 Mar 7 15:15:11 unRAID dnsmasq[14786]: compile time options: IPv6 GNU-getopt no-DBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth no-DNSSEC loop-detect inotify dumpfile Mar 7 15:15:11 unRAID dnsmasq-dhcp[14786]: DHCP, IP range 192.168.122.2 -- 192.168.122.254, lease time 1h Mar 7 15:15:11 unRAID dnsmasq-dhcp[14786]: DHCP, sockets bound exclusively to interface virbr0 Mar 7 15:15:11 unRAID dnsmasq[14786]: reading /etc/resolv.conf Mar 7 15:15:11 unRAID dnsmasq[14786]: using nameserver 8.8.8.8#53 Mar 7 15:15:11 unRAID dnsmasq[14786]: using nameserver 8.8.4.4#53 Mar 7 15:15:11 unRAID dnsmasq[14786]: read /etc/hosts - 2 addresses Mar 7 15:15:11 unRAID dnsmasq[14786]: read /var/lib/libvirt/dnsmasq/default.addnhosts - 0 addresses Mar 7 15:15:11 unRAID dnsmasq-dhcp[14786]: read /var/lib/libvirt/dnsmasq/default.hostsfile Mar 7 15:15:11 unRAID kernel: virbr0: port 1(virbr0-nic) entered disabled state Mar 7 15:15:11 unRAID kernel: L1TF CPU bug present and SMT on, data leak possible. See CVE-2018-3646 and https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html for details. Mar 7 15:15:12 unRAID tips.and.tweaks: Tweaks Applied Mar 7 15:15:12 unRAID unassigned.devices: Mounting 'Auto Mount' Remote Shares... Mar 7 15:15:12 unRAID sudo: root : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/bin/bash -c /usr/local/emhttp/plugins/unbalance/unbalance -port 6237 Mar 7 15:15:13 unRAID kernel: br0: port 2(vnet0) entered blocking state Mar 7 15:15:13 unRAID kernel: br0: port 2(vnet0) entered disabled state Mar 7 15:15:13 unRAID kernel: device vnet0 entered promiscuous mode Mar 7 15:15:13 unRAID kernel: br0: port 2(vnet0) entered blocking state Mar 7 15:15:13 unRAID kernel: br0: port 2(vnet0) entered forwarding state Mar 7 15:15:14 unRAID kernel: e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None Mar 7 15:15:14 unRAID kernel: bond0: link status definitely up for interface eth0, 1000 Mbps full duplex Mar 7 15:15:15 unRAID avahi-daemon[10987]: Joining mDNS multicast group on interface vnet0.IPv6 with address fe80::fc54:ff:fe00:f65e. Mar 7 15:15:15 unRAID avahi-daemon[10987]: New relevant interface vnet0.IPv6 for mDNS. Mar 7 15:15:15 unRAID avahi-daemon[10987]: Registering new address record for fe80::fc54:ff:fe00:f65e on vnet0.*. Mar 7 15:16:20 unRAID ntpd[1875]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized Mar 7 15:17:13 unRAID unassigned.devices: Cannot 'Auto Mount' Remote Shares. Network not available! Mar 7 15:18:16 unRAID login[10849]: ROOT LOGIN on '/dev/tty1' What the heck is happening?