Glassed Silver

@Squid I'm really sorry to ping you, but I haven't found any comment from you on the docker update notification spam situation so far (maybe I didn't use the search correctly or used the wrong terms, idk...) Is it an issue you're aware of and that we can expect a fix for some time soon-ish? I don't think FCP really needs to check on any of my docker containers, I auto-update a lot and I also manually update some of them all on my own, if we could exclude that check, that'd be so helpful, especially as it would decrease the processing needed. Getting daily notifications about some dozen or so containers having an update available at a given moment is very unhelpful since it buries any possible errors that are left unseen since I notice myself just swiping away all of my Pushover notifications in bulk sometimes when I don't have time for minor stuff like that. In any case thank you so much for this wonderful plug-in!

Fair enough, but then how do I get it to download a version that's not rather old? latest gave me version 102, which happens to be what Debian's repo has. Okay, I just investigated. Apparently you use the FF ESR/Thunderbird ppa, that one only offers 102 as latest for Thunderbird. It'd be nice if you could make it an option to use their thunderbird-next repo instead through a variable. However it's nice to see you don't rely on Debian for the main third-party packages that supply reliable repos themselves. Other than that, thank you so much for the container.

Any reason why the Thunderbird container doesn't let me pick unstable? The Debian repo might not be the best source to reference for packages that need to be very up-to-date... I'd suggest adding the Mozilla repo apt repo and sourcing from there upon every reboot of the container rather than pulling from Debian. Being stuck 14-15 versions behind is no laughing matter when you try to be using the latest release and unstable is unavailable as a tag. And if it's not too much to ask, do you have any plans to switch to kasmvnc over novlc?

I don't have the GPU Stat plugin and get this error logged anyhow. Since unRAID primarily works off a web UI and is typically extended by running heaps of plugins that seem to rely on this setting being set correctly, probably preferably higher than what it's set to by default I'd suggest LimeTech to look into this a little closer. I recently re-did my docker config since I switched from a btrfs vdisk to folders on a ZFS cache pool and the more dockers I added back from my stored templates the slower the UI got, and I bet this has something to do with it as well. I have over 90 dockers (before anyone feels an itch: I'm not here to justify my setup, you will not see me entertain this discussion...) unRAID's web UI HAS to scale better with large needs, this has been an issue for years now and as you extend your use cases for unRAID the UI punishes you much for it.

Could it be none of your dockers use br0?

Probably a good idea to post this into a dedicated thread if you ask me. off-topic/rant: The longer I am on 6.11.5/6.12.x the more I wish I had heeded the cautious lessons of MACVLAN issues and remained on 6.9.2 until resolved, That being said, a few weeks ago I didn't know I'd get a Fritz!Box router...

Sure, those definitely are aspects that still need to be worked on, but this lifts ZFS from a very difficult to plan for FS for homelabbers who are attracted by unRAID's unique selling points to something that makes it workable where the remaining hurdles are a lot easier (and cheaper) to mitigate. It most certainly is 80% of the way. Way more than a little if you ask me.

A little? This is in my opinion the ONE change most homelabbers will have waited for if they want to expand as they go rather than moving, recreating pools, keeping money invested in drives that you wouldn't need storage-wise, etc... I for one am ECSTATICb and cannot wait for this to land in unRAID. Glorious times, the single-most imporant feature I've been waiting for for sure for unRAID.

More eyes = more bugs found. Beta tests and RCs are done by few people, gold releases are done by everyone except for the few who are cautious.

Yeah, IPVLAN is fine, problem is that not for all of us that's a viable option. LimeTech seems to like to pretend it is, unless they simply are too busy catching up with this mess and want to communicate betterment once they figured it out. Personally communication should come first, but sadly this is the kind of behavior I always feared to experience at some point down the line with a proprietary and commercial product that's based on community development and support so much. Happy day when LT steers this ship around again, love unRAID regardless, but for a server OS this is becoming a bit of a sour tale.

At this point I'd already be happy seeing LimeTech publicly acknowledging the issue and communicating they are looking into it. The status quo seems to be based on letting the community figure it out with a variety of workarounds and hacks which I find problematic at best and concerning at worst.

1) I think you misunderstood what I meant, my point is you should tell users that you fall back to latest. 2) As for the different point that Nvidia could drop legacy drivers anytime.... Sure... Then update the plugin to drop the channel? In any case that wasn't even my point.

If your plugin is that opinionated maybe you should provide information about that within it? Not trying to sound sour, I don't even have a GPU in my unRAID server, but I may at some point. It could avoid confusion. Just thinking aloud.

I know.

I do have a FritzBox, indeed. Right now I have a stable system only because I deactivated Docker, but obviously at some point I'd like to use one of the main features of the OS I paid for again. As for what I need static IPs for: services the need to be reachable at all times from a reliable address regardless of DHCP and DNS.

Sadly MACVLAN is needed for static IPs and for some routers that don't support multiple IPs for a single MAC address...

Absolutely beyond me how this remained an issue for so long when macvlan was FINE before. Having static IPs for dockers is no niche need and getting server lockups as frequently as I got them the past few weeks when 6.9.2 ran like a roadrunner for over a year without downtime is... It's just really weird. If the issue is higher level I'm sure LimeTech could get in touch with those who are closer to the meat and potatoes of this issue, the OS may be based on FOSS, but in the end it's a paid product advertising to be a cheaper, but more customizable and functional alternative to off-the-shelf NAS systems for tech savvy folks. The most painful thing is that I had been wondering forever what my troubles could be and what I'm doing wrong. Turns out, I'm not doing anything crazy that shouldn't be possible and just in time I'm joining the ranks of FritzBox users in the coming days. Oh Lordie... So even if I didn't need static IPs for some dockers, I'd be SOL the moment I switch to my new router.

Array started, I feel alive again! Here's to hoping every service gets back up flawlessly, but since it mounted without any hiccup right away after that command I'm feeling optimistic. Thank you so very much, you didn't just make my day, you made my week. Truly thank you from the bottom of my heart, @JorgeB!

Alright, sounds like a good compromise, thank you so much for willing to help on those terms. Here's a snippet of around the mount attempt. If you need more, like you suggested I'll merrily provide more. Jun 20 22:43:20 Ahri kernel: scsi 1:0:6:0: Direct-Access ATA TOSHIBA MG08ACA1 0102 PQ: 0 ANSI: 6 Jun 20 22:43:20 Ahri kernel: scsi 1:0:6:0: SATA: handle(0x0010), sas_addr(0x5001438024fdabe7), phy(6), device_name(0x5000039af8d2f414) Jun 20 22:43:20 Ahri kernel: sd 1:0:0:0: [sdb] Attached SCSI disk Jun 20 22:43:20 Ahri kernel: scsi 1:0:6:0: enclosure logical id (0x5001438024fdabe0), slot(7) Jun 20 22:43:20 Ahri kernel: scsi 1:0:6:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y) Jun 20 22:43:20 Ahri kernel: scsi 1:0:6:0: qdepth(32), tagged(1), scsi_level(7), cmd_que(1) Jun 20 22:43:20 Ahri kernel: sdc: sdc1 Jun 20 22:43:20 Ahri kernel: sd 1:0:1:0: [sdc] Attached SCSI disk Jun 20 22:43:20 Ahri kernel: sdf: sdf1 Jun 20 22:43:20 Ahri kernel: sd 1:0:4:0: [sdf] Attached SCSI disk Jun 20 22:43:20 Ahri kernel: sde: sde1 Jun 20 22:43:20 Ahri kernel: sd 1:0:3:0: [sde] Attached SCSI disk Jun 20 22:43:20 Ahri kernel: sdd: sdd1 Jun 20 22:43:20 Ahri kernel: sd 1:0:2:0: [sdd] Attached SCSI disk Jun 20 22:43:20 Ahri kernel: sdg: sdg1 Jun 20 22:43:20 Ahri kernel: sd 1:0:5:0: [sdg] Attached SCSI disk Jun 20 22:43:20 Ahri kernel: sd 1:0:6:0: Attached scsi generic sg7 type 0 Jun 20 22:43:20 Ahri kernel: end_device-1:0:6: add: handle(0x0010), sas_addr(0x5001438024fdabe7) Jun 20 22:43:20 Ahri kernel: sd 1:0:6:0: [sdh] 27344764928 512-byte logical blocks: (14.0 TB/12.7 TiB) Jun 20 22:43:20 Ahri kernel: sd 1:0:6:0: [sdh] 4096-byte physical blocks Jun 20 22:43:20 Ahri kernel: scsi 1:0:7:0: Direct-Access ATA TOSHIBA MG08ACA1 0102 PQ: 0 ANSI: 6 Jun 20 22:43:20 Ahri kernel: scsi 1:0:7:0: SATA: handle(0x0011), sas_addr(0x5001438024fdabe8), phy(7), device_name(0x5000039af8d2e434) Jun 20 22:43:20 Ahri kernel: scsi 1:0:7:0: enclosure logical id (0x5001438024fdabe0), slot(8) Jun 20 22:43:20 Ahri kernel: scsi 1:0:7:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y) Jun 20 22:43:20 Ahri kernel: scsi 1:0:7:0: qdepth(32), tagged(1), scsi_level(7), cmd_que(1) Jun 20 22:43:20 Ahri kernel: sd 1:0:6:0: [sdh] Write Protect is off Jun 20 22:43:20 Ahri kernel: sd 1:0:6:0: [sdh] Mode Sense: 7f 00 00 08 Jun 20 22:43:20 Ahri kernel: sd 1:0:6:0: [sdh] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Jun 20 22:43:20 Ahri kernel: sdh: sdh1 Jun 20 22:43:20 Ahri kernel: sd 1:0:6:0: [sdh] Attached SCSI disk Jun 20 22:43:20 Ahri kernel: sd 1:0:7:0: Attached scsi generic sg8 type 0 Jun 20 22:43:20 Ahri kernel: end_device-1:0:7: add: handle(0x0011), sas_addr(0x5001438024fdabe8) Jun 20 22:43:20 Ahri kernel: scsi 1:0:8:0: Direct-Access ATA Samsung SSD 860 4B6Q PQ: 0 ANSI: 6 Jun 20 22:43:20 Ahri kernel: scsi 1:0:8:0: SATA: handle(0x0012), sas_addr(0x5001438024fdabed), phy(12), device_name(0x5002538e90804b01) Jun 20 22:43:20 Ahri kernel: scsi 1:0:8:0: enclosure logical id (0x5001438024fdabe0), slot(13) Jun 20 22:43:20 Ahri kernel: scsi 1:0:8:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y) Jun 20 22:43:20 Ahri kernel: scsi 1:0:8:0: qdepth(32), tagged(1), scsi_level(7), cmd_que(1) Jun 20 22:43:20 Ahri kernel: sd 1:0:7:0: [sdi] 27344764928 512-byte logical blocks: (14.0 TB/12.7 TiB) Jun 20 22:43:20 Ahri kernel: sd 1:0:7:0: [sdi] 4096-byte physical blocks Jun 20 22:43:20 Ahri kernel: sd 1:0:8:0: Attached scsi generic sg9 type 0 Jun 20 22:43:20 Ahri kernel: end_device-1:0:8: add: handle(0x0012), sas_addr(0x5001438024fdabed) Jun 20 22:43:20 Ahri kernel: sd 1:0:8:0: [sdj] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB) Jun 20 22:43:20 Ahri kernel: sd 1:0:7:0: [sdi] Write Protect is off Jun 20 22:43:20 Ahri kernel: scsi 1:0:9:0: Direct-Access ATA Samsung SSD 860 4B6Q PQ: 0 ANSI: 6 Jun 20 22:43:20 Ahri kernel: scsi 1:0:9:0: SATA: handle(0x0013), sas_addr(0x5001438024fdabee), phy(13), device_name(0x5002538e702b1ef3) Jun 20 22:43:20 Ahri kernel: scsi 1:0:9:0: enclosure logical id (0x5001438024fdabe0), slot(14) Jun 20 22:43:20 Ahri kernel: scsi 1:0:9:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y) Jun 20 22:43:20 Ahri kernel: scsi 1:0:9:0: qdepth(32), tagged(1), scsi_level(7), cmd_que(1) Jun 20 22:43:20 Ahri kernel: sd 1:0:9:0: Attached scsi generic sg10 type 0 Jun 20 22:43:20 Ahri kernel: end_device-1:0:9: add: handle(0x0013), sas_addr(0x5001438024fdabee) Jun 20 22:43:20 Ahri kernel: scsi 1:0:10:0: Enclosure HP Gen8 ServBP 12+2 3.30 PQ: 0 ANSI: 5 Jun 20 22:43:20 Ahri kernel: sd 1:0:7:0: [sdi] Mode Sense: 7f 00 00 08 Jun 20 22:43:20 Ahri kernel: sd 1:0:9:0: [sdk] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB) Jun 20 22:43:20 Ahri kernel: scsi 1:0:10:0: set ignore_delay_remove for handle(0x0014) Jun 20 22:43:20 Ahri kernel: scsi 1:0:10:0: SES: handle(0x0014), sas_addr(0x5001438024fdabf9), phy(24), device_name(0x0000000000000000) Jun 20 22:43:20 Ahri kernel: scsi 1:0:10:0: enclosure logical id (0x5001438024fdabe0), slot(0) Jun 20 22:43:20 Ahri kernel: scsi 1:0:10:0: qdepth(1), tagged(0), scsi_level(6), cmd_que(0) Jun 20 22:43:20 Ahri kernel: sd 1:0:8:0: [sdj] Write Protect is off Jun 20 22:43:20 Ahri kernel: sd 1:0:8:0: [sdj] Mode Sense: 7f 00 00 08 Jun 20 22:43:20 Ahri kernel: sd 1:0:9:0: [sdk] Write Protect is off Jun 20 22:43:20 Ahri kernel: sd 1:0:9:0: [sdk] Mode Sense: 7f 00 00 08 Jun 20 22:43:20 Ahri kernel: sd 1:0:8:0: [sdj] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Jun 20 22:43:20 Ahri kernel: sd 1:0:9:0: [sdk] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Jun 20 22:43:20 Ahri kernel: scsi 1:0:10:0: Attached scsi generic sg11 type 13 Jun 20 22:43:20 Ahri kernel: end_device-1:0:10: add: handle(0x0014), sas_addr(0x5001438024fdabf9) Jun 20 22:43:20 Ahri kernel: sdj: sdj1 Jun 20 22:43:20 Ahri kernel: sdk: sdk1 Jun 20 22:43:20 Ahri kernel: sd 1:0:8:0: [sdj] Attached SCSI disk Jun 20 22:43:20 Ahri kernel: sd 1:0:9:0: [sdk] Attached SCSI disk Jun 20 22:43:20 Ahri kernel: sd 1:0:7:0: [sdi] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Jun 20 22:43:20 Ahri kernel: sdi: sdi1 Jun 20 22:43:20 Ahri kernel: sd 1:0:7:0: [sdi] Attached SCSI disk Jun 20 22:43:20 Ahri kernel: ata2: SATA link down (SStatus 0 SControl 300) Jun 20 22:43:20 Ahri kernel: ata3: SATA link down (SStatus 0 SControl 300) Jun 20 22:43:20 Ahri kernel: ata4: SATA link down (SStatus 0 SControl 300) Jun 20 22:43:20 Ahri kernel: ata5: SATA link down (SStatus 0 SControl 300) Jun 20 22:43:20 Ahri kernel: ata6: SATA link down (SStatus 0 SControl 300) Jun 20 22:43:20 Ahri kernel: mgag200 0000:01:00.1: vgaarb: deactivate vga console Jun 20 22:43:20 Ahri kernel: Console: switching to colour dummy device 80x25 Jun 20 22:43:20 Ahri kernel: [drm] Initialized mgag200 1.0.0 20110418 for 0000:01:00.1 on minor 0 Jun 20 22:43:20 Ahri kernel: fbcon: mgag200drmfb (fb0) is primary device Jun 20 22:43:20 Ahri kernel: mgag200 0000:01:00.1: [drm] drm_plane_enable_fb_damage_clips() not called Jun 20 22:43:20 Ahri kernel: BTRFS: device fsid b8c88925-d8be-4ab9-8ef8-17484fdafe91 devid 1 transid 4309837 /dev/sdd1 scanned by udevd (1083) Jun 20 22:43:20 Ahri kernel: BTRFS: device fsid 878890c5-81f9-4f8f-8f69-818e2af4175e devid 1 transid 360242 /dev/sdf1 scanned by udevd (1057) Jun 20 22:43:20 Ahri kernel: BTRFS: device fsid c2923828-e4c3-483e-bc45-ba3fe7ef2b6a devid 1 transid 5985837 /dev/sdb1 scanned by udevd (1038) Jun 20 22:43:20 Ahri kernel: BTRFS: device fsid 943d58d4-9214-47a8-8d61-01272b03f9ba devid 1 transid 368310 /dev/sdg1 scanned by udevd (1083) Jun 20 22:43:20 Ahri kernel: BTRFS: device fsid 71dab375-beb9-4327-bea1-6a7ac48dcd5f devid 1 transid 133339 /dev/sde1 scanned by udevd (1038) Jun 20 22:43:20 Ahri kernel: BTRFS: device fsid 979bf416-df16-4476-91f0-ea4e6c4084b2 devid 1 transid 1796375 /dev/sdc1 scanned by udevd (1057) Jun 20 22:43:20 Ahri kernel: BTRFS: device fsid d5b29014-e26e-4407-a52d-73db030f39ef devid 2 transid 44263972 /dev/sdk1 scanned by udevd (1057) Jun 20 22:43:20 Ahri kernel: Console: switching to colour frame buffer device 128x48 Jun 20 22:43:20 Ahri kernel: BTRFS: device fsid d5b29014-e26e-4407-a52d-73db030f39ef devid 1 transid 44263972 /dev/sdj1 scanned by udevd (1083) Jun 20 22:43:20 Ahri kernel: mgag200 0000:01:00.1: [drm] fb0: mgag200drmfb frame buffer device Jun 20 22:43:20 Ahri kernel: igb 0000:02:00.3: removed PHC on eth3 Jun 20 22:43:20 Ahri kernel: igb 0000:02:00.2: removed PHC on eth2 Jun 20 22:43:20 Ahri kernel: igb 0000:02:00.1: removed PHC on eth1 Jun 20 22:43:20 Ahri kernel: igb 0000:02:00.0: removed PHC on eth0 Jun 20 22:43:20 Ahri kernel: igb: Intel(R) Gigabit Ethernet Network Driver Jun 20 22:43:20 Ahri kernel: igb: Copyright (c) 2007-2014 Intel Corporation. Jun 20 22:43:20 Ahri kernel: igb 0000:02:00.0: added PHC on eth0 Jun 20 22:43:20 Ahri kernel: igb 0000:02:00.0: Intel(R) Gigabit Ethernet Network Connection

I'll DM you the password for the file, because I really don't feel comfortable putting up info like this publicly. https://drive.google.com/file/d/1Zw4NvfVu0YSxuaKYmTdsy01Xh85U45bR/view?usp=drivesdk If you decide to help me out you have all my thanks and appreciation in advance already. Cheers

I decided to reboot after noticing that my docker image was unreadable as well as /mnt/user/system and anything below it. I decided to reboot and now my cache pool of two drives won't mount. Brining my array into maintenance mode yielded me this on the read-only filesystem check against my cache pool: [1/7] checking root items [2/7] checking extents [3/7] checking free space tree free space info recorded 1351 extents, counted 1361 There are still entries left in the space cache cache appears valid but isn't 6182821691392 [4/7] checking fs roots [5/7] checking only csums items (without verifying data) [6/7] checking root refs [7/7] checking quota groups skipped (not enabled on this FS) Opening filesystem to check... Checking filesystem on /dev/sdj1 UUID: d5b29014-e26e-4407-a52d-73db030f39ef found 759680454656 bytes used, error(s) found total csum bytes: 236747020 total tree bytes: 1881374720 total fs tree bytes: 1275772928 total extent tree bytes: 314228736 btree space waste bytes: 386624833 file data blocks allocated: 7470265802752 referenced 690431000576 Should I run the check without the read-only parameter? I will provide any diagnostics that are asked for, but I will not read megabytes of compressed files trying to censor them for privacy.

I'm sorry to generate a notification for you and not come around with an answer, but I just want to express that I'm wondering the exact same thing right now. I'd love to do this with a reverse proxy without giving a card-blanche to all containers.

Getting rid of the Docker tab sounds horrible and insisting on keeping that Action Centre enabled notification active is.... a really odd choice to be fair. Docker containers and plugins are not just different delivery algorythms to achieve the same in my honest opinion. Plugins typically extend the capability of the host OS and docker applications are more like user apps. To me those are severely differnt things. I'm really puzzled by those views. I also don't think having the app store and the app presentation of already installed apps as a unified place in one tab is major UX progress. More nesting does not always equal more simplicity and overview....

Tauchen die docker eigentlich auch als hosts im Netz sichtbar auf (z.B. im Router) wenn du keine Ports mappst? Oder behält Docker die dann für sich und lässt gut sein? Mir wäre es lieber wenn die Docker alle keine IPv6-Adressen hätten, sondern IPv6 nur auflösen und erreichen könnten. Also docker-internes IPv6to4 oder so. Aber wenn ich dann hinterher Dutzende Einträge mehr im Router habe dann sollls wohl so sein...

What did you set for PUID and PGID? Confirm it's the same as when you run this from the container's shell: id What you set and what displays there should definitely match, this is basically a sanity check for my template. Where I expect a deviation is your files as you already guessed. To confirm and fix in that case: From the container's shell again, run this command against the Uploads, Extensions and if applicable Database folders' mapped locations: ls -lh like so ls -lh /directus/uploads/ ls -lh /directus/extensions/ ls -lh /directus/database/ You only need to check the last one if you use SQLite rather than a dedicated database backend. To fix, if needed run this, should work from the container's shell again, if not, change the paths to the mapped host paths and run from unRAID's shell: chmod <PUID>:<PGID> -R /directus/uploads/ chmod <PUID>:<PGID> -R /directus/extensions/ chmod <PUID>:<PGID> -R /directus/database/ Lastly run this command against the same directories: chown 755 -R /directus/uploads/ chown 755 -R /directus/extensions/ chown 755 -R /directus/database/ That should do it 👍