lining7333

For anyone having issues after an initial install, I'd suggest searching the "container-support" channel in linuxserver's Discord. (The Discord invite link is on the Github page.) There, I saw suggestions that got the container to work for me. For example, someone said to set the MAC address in the container config to your machine's MAC (which on Unraid can be found in Settings -> Network Settings) or to use a randomly generated MAC. I also fonud the command for running the EPG grabbing manually: "docker exec -it webgrabplus bash", and then "run /app/update.sh". Assuming you have added your webgrabplus.com login details correctly into your WebGrab++.config.xml file, the command should work. For other info on setting up my config file, I referenced https://webgrabplusguide.github.io/.

Some potentially useful info after it happened again just now (marking the 3rd time overall): My docker containers and VM were still accessible even after the error banner appeared and the docker/VM tabs disappeared. Sounds similar to what was happening here: I already installed the "Flash Remount" plugin as a precaution after my initial flash issue, so that hasn't been helping apparently. Not sure what else to do, if anything, until my new flash drive arrives tomorrow. EDIT: Not sure it will make a difference since I already upgraded Unraid successfully in the days between flash incidents #1 and #2, but as a possible usb fix I just replaced all the bz* files at the root of the flash drive with those from a fresh Unraid download, as suggested in places like this: Will see how it goes.

Update: After a few days, it's happened again. I went through the same process as before: the banner warning appeared, then the flash drive seemingly wasn't found on reboot since Dell's hardware check kicked in, I ran a First Aid repair on the USB with my Mac, and Unraid successfully booted again after switching ports. That's twice this week; I've been running Unraid for more than a year and haven't experienced this prior. I'm not sure what might have changed recently that could be causing this. I've ordered a new flash drive to be safe, but I'm worried the problem might persist if the drive isn't the root issue. I've attached new diagnostics -- one from after the error but before reboot, and another from after reboot. Any ideas? EDIT: I should note that the same "rc.usb_manager" lines didn't seem to appear in the logs before the flash errors started this time, so I'm guessing it might not be the possible issue noted by @trurl last time, though I'm not 100% sure. optiplex-diagnostics-20250508-0924.zip optiplex-diagnostics-20250508-1115.zip

Hey thanks @trurl, that seems like a good clue. You're right that they are on the same USB controller. For now, I will make sure that the vm_action command doesn't fire anymore, and I will look into getting a separate controller. Will update thread if anything else happens.

Got the "your flash drive is corrupted or offline" banner today. The docker tab and I think the VM tab disappeared at this time. I grabbed the diagnostics before rebooting and my machine apparently didn't recognize the flash drive, as some kind of Dell system check did a scan unprompted; it said everything was fine with my hardware. So I powered down the machine, plugged the flash drive into Mac and ran a First Aid repair on it in Disk Utility. Disk Utility said the repair completed successfully. I plugged flash drive into a new USB slot on Dell (I believe both the old and new slots are USB2, on the front of my Optiplex). Then Unraid booted up fine, although the Unraid logo in the upper left corner of the window appeared doubled and there was an error on the bell symbol in the top right that the Unraid API was unavailable. (These fixed themselves after a few moments.) I then downloaded a backup of the flash drive from the GUI and grabbed the diagnostics again (just in case). Could someone pleased take a look and tell me if I should replace my USB or take other action? Thanks in advance. optiplex-diagnostics-20250504-1921.zip optiplex-diagnostics-20250504-1824.zip

Perhaps this is obvious to more advanced users, but it took me a long time to realize that using a hyphen in my stack names was causing errors. When I executed "docker compose up" in the command line / terminal with those stacks, they would run successfully but the Compose GUI wouldn't show the green arrows next to them and wouldn't allow me to use their "compose down" buttons. For anyone else searching this thread for "hyphen" or "dash," make sure to remove them.

Hey right before you replied, I finally got it working with the help of Docker compose. (I didn't even check the error logs because I'm not a smart person!) I'll update this post in a bit with screenshots of my compose file. EDIT: Here's my working compose file. I was also going to include a screenshot of my postgres config, but I realized it's essentially the same as the default 12.5 template in Community Applications, along with Joshndroid's exact instructions for setting the container/database up correctly. services: invidious: network_mode: bridge container_name: invidious image: quay.io/invidious/invidious:master # image: quay.io/invidious/invidious:latest-arm64 # ARM64/AArch64 devices restart: unless-stopped ports: # - "127.0.0.1:3000:3000" - 3000:3000 environment: # Please read the following file for a comprehensive list of all available # configuration options and their associated syntax: # https://github.com/iv-org/invidious/blob/master/config/config.example.yml INVIDIOUS_CONFIG: | db: dbname: invidious user: kemal password: kemal host: [my Unraid IP address] port: 5432 check_tables: true signature_server: 172.17.0.20:12999 visitor_data: [my visitor_data string] po_token: [my po_token] # external_port: # domain: # https_only: false # statistics_enabled: false hmac_key: [my hmac_key] healthcheck: test: wget -nv --tries=1 --spider http://127.0.0.1:3000/api/v1/trending || exit 1 interval: 30s timeout: 5s retries: 2 logging: options: max-size: "1G" max-file: "4" inv_sig_helper: container_name: inv_sig_helper network_mode: bridge image: quay.io/invidious/inv-sig-helper init: true command: ["--tcp", "172.17.0.20:12999"] environment: - RUST_LOG=info restart: unless-stopped cap_drop: - ALL read_only: true security_opt: - no-new-privileges:true

For Invidious: Can anyone share screenshots of a fully working setup of their invidious and inv_sig_helper containers? Preferably without Portainer, since I don't have that. I followed the initial Invidious setup guide from Joshndroid, and postgres and Invidious seemed to work at that point (except, of course, I couldn't play videos in the Invidious GUI due to that recent* Google block), But once I tried to add in inv_sig_helper and modify Invidious, I kept getting constant errors. I kept track of all the different ways I've tried to get them to work so far, and it adds up to 24 attempts in total, so I'm at a loss. I'm sure it's something simple, but I can't crack it.

Thanks, after waiting a day to see if this would work, it looks like it does! I wouldn't have thought to quit luckybackup within its GUI in order to save the email settings.

luckyBackup question: I can correctly set up the email configuration and receive a test email, but when the container restarts each morning my email settings seem to be wiped. The task list maintains any changes I've made (say, to the target folder or the cronjob time, for example), while the email settings are totally cleared -- not just my email login info, but also the condition to run is set back to "never" instead of "errors occurred." It's like I never filled out the info in the first place. Any idea why? I appreciate your help!