binhex

ok then im out of ideas, all i can say is i use this image and it works for me *shrug*.

it looks like this maybe related to out of date mono, so i have kicked off the build again, please pull down latest in around 30 mins from now and report back.

Correct Sent from my 22021211RG using Tapatalk

Yeah, this is the problem with bundling more and more stuff into the image, as soon as anything goes out of date people want the image rebuilding, so I'm loathed to include stuff that changes frequently, especially stuff that is not necessary, sorry but its a no to including it.

check its not database corruption (common), Q4:- https://github.com/binhex/documentation/blob/master/docker/faq/plex.md

OK thanks for that, so it looks like the package 'kio' includes sftp and it looks like the package version has now bumped up to 'kio5' which once included in the build meant that sftp was available again (amongst other additional functionality). Hey no worries, everyone has stuff going on in their lives, i hope you are ok.

i fixed up the broken github action for the base (it was on my todo list) which then kicked off the intermediate image builds, once done then i re-crated the krusader image, and due to the fact there were no updates as the base image is now up to date, the size of the image was dramatically reduced. from now on we should be back to more frequent automated base image builds, which should help alleviate any large increases in image size due to update churn.

hmm ok in that case it looks good to me, i have no idea why it's being blocked by zerotier.

you really wont gain any security by obfuscating that tbh, its an internal ip, but in any case unless x=0 for 10.0.10.x then its misconfigured, see Q4:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

sorry dude but there is nothing i can do about this as it's an unraid related issue, the image is accessible and for me i cannot reproduce the issue you are seeing. you could try deleting the container completely, then re-create it, this may fix it *shrug*.

this looks like the classic caching/cookies issue, try clearing down cookies/cache, try another browser, try incognito mode, one of those should get you going. FWIW i can confirm the latest image is working for me

It is purely informational, it's not an error or warning Sent from my 22021211RG using Tapatalk

the base os i use is arch linux, this is a rolling distro which means i need to update all packages if i want to pick up the latest versions of packages pushed to arch linux repository and because docker images are built in immutable layers this can lead to larger image sizes depending on when the base image was last built, so the size will vary somewhat, this is compounded for this image as it requires a lot of packages due to the fact its running a gui. I have not built the base in a while due to an ongoing issue, so i will take a look at it and see if i can fix it up and then kick off a new build of this image which should result in a reduction in the image size (nothing to update).

Yes i do bind multiple containers together via a single vpn container (privoxyvpn), but you will not receive an incoming port for the other containers, so if it's a torrent client (for example) then your only option to assign an incoming port is to create another separate vpn container, most vpn providers permit multiple connections, PIA i think gives you 5.

i have never thought of doing that!!, you won't get a incoming port for the second container and thus your speeds will be low, you know that right?. seriously, don't do this!, this is not what it's used for, see warning:-

the lan_network is wrong, see Q4:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

you need to ensure iptable_mangle is loaded and available on your host.

sorry i completely forgot about this post!, the above looks fine and i can see its using 'bridge' and not sharing the network with any vpn docker containers, so i am puzzled as to why prowlarr cannot connect, the URL you are entering into prowlarr for the 'host' is that the ip address of your unraid server, right?.

it will be included in the next build.

Ah had time to do some more digging, so looks like there are two versions of ffmpeg included, emby-ffmpeg and ffmpeg, and its the former that needs to be updated, so i have contacted the upstream dev about the issue, hopefully he should pick up my message and if he agrees then should bump the package version and i can then rebuild and we should be good.

I've tried everything!, im currently out of ideas as to the cause 😞

i am confident the image is fine as other people have pulled it down with no issue (including myself) so the issue you are seeing is either specific to your network in some way or it's an unraid bug that you are seeing, so i think it's worth a post there and see what people say.

A quick google search reveals that this sort of error is most common due to bad source file, does this happen with ALL files or just the odd one?.

Not true, Arch tend to include bleeding edge stable releases and this image is no different, it includes ffmpeg 6.1.1, from the container:- ffmpeg version n6.1.1 Copyright (c) 2000-2023 the FFmpeg developers What is causing your issue i'm not sure, but its definitely not due to out of date ffmpeg.

i didn't knowingly include or remove sftp, there has been no alterations to the code, it was simply a re-triggered build from a upstream change. Can you detail how you previously used sftp in this container, that way i can then investigate why it got removed and how to add it back in.