clambert

Did you ever figure out what was causing this problem? I am having the very same problem.

So has anyone else had sync issues recently with Plex v4.51.3 depending on the source file? I know it's not the fault of the container but didn't know if anyone else is seeing this? The client is a Tube Shield TV and web on a Chromebook.

Did you set the built in apc ups settings to No, simple and dumb? You may need to restart. The apcupsd may still have a hold on your ups I had the built in UPS setting set to No. The other settings were USB and I changed them to simple and dumb. After a reboot I seem to have similar issues. I've tried with enable manual config on and off. I'm not sure what's the right way to do this. HERE is the new output when I run rc.nut start, as well as the settings in each config. I'm a noob to this so maybe I'm missing something. I only edited the ups.conf. I've read where people seem to have had issues with Tripp Lite UPS'. Maybe it's a fruitless battle. Any help is appreciate if there is something else to try.

So I am trying to get NUT working with my Tripp Lite OMNI1500LCDT UPS because the UPS APC daemon within Unraid isn't working properly. When I auto-detect within NUT it seems to find the info it seems but NUT is not starting. HERE is the info I see when doing /etc/rc.d/rc.nut start. Does anyone have an idea of what I might be able to do to get NUT to function with my UPS?

I'm on 1.4.0 and everything seems fine with my container. My Unraid version is 6.8.2 for what it's worth.

Just wait until the container updates. In Unraid you can easily auto-update. I do this after I backup my appdata every night. You can elect to obviously just wait and update the container when a new version is available.

So I'm running the latest Docker version of Syncthing. So far I really like it. One thing doesn't work like I would expect. I backup my app data and auto-update the container. Every morning the Recent Changes log is empty. Is there a setting that makes this persistent when restarting the container?

So I got this back just by deleting the container and copying over the old data. Is there a way to get this to work properly in a reverse proxy or isn't it such a good idea? Really I suppose it's unnecessary.

So I had the latest binhex-Plex working just fine. Today I moved Plex behind a reverse proxy and something seems to have stopped working properly. The WebUI is no longer available to the container and Plex is not available via my local IP. Oddly enough it works via Plex.tv and the reverse proxy. I tried to change the container back to normal, outside the proxy but the WebUI is still not available if I right click the container. According to some reading in this thread, it might be a permission issue. Does anyone know how to fix this? I tried deleting the perms.txt file but it didn't seem to do any good. I'd like it in the reverse proxy but it's honestly not necessary. I do want to run it locally. Any help is greatly appreciated.

So yeah, I did get it working by watching that video. I guess I was a little confused because I thought the thread mentioned being able to do it without enabling SMB 1. In the video SI One has us enable it. That's what I have done for now. It's fine I guess. Thanks for the help.

So I am getting the Error Code 0x80004005 on Windows 10 Build 18362. Enabling this value doesn't seem to work for me. Are there any other known tricks?

Ah. Ok. Thanks for the info. All this kinda rings true to the problems I was having before when I gave up after updating. I just couldn't get the UI to load. My assumption at the time was that I couldn't get the Docker container running. Now that I know there is a solution out there I'll starting digging around in the Synology forums. For what it's worth changing the value to 'yes' does prevent my WebUI from loading. Thank you for the point in the right direction.

Ok, I already had debug set to true. I just deleted the log to start fresh, started the container, went to IPMagnet, and downloaded the torrent. The IP matched my public IP. Attached is the log you requested. I'm sure it's something stupid I've done. Thanks for the help! I'm using PIA and just checked the credentials. They seem to be valid. I have DelugeVPN running on my Synology NAS for what it's worth. supervisord.log

Hmmm... That wasn't in my list of environmental variables from my old install from 1.5 years ago. I most likely missed adding it back in the day when I was playing around. I had it working perfectly at one time. I then updated the Docker container eventually and everything fell apart and it stopped working for me. Eventually I just gave up because I honestly don't torrent all that much. The other day I felt like playing around with it again and I just carried over my existing settings. At any rate it was my stupid mistake. I'll give it a go again and try to be more careful. 😂 [EDIT] Oh snap. I just realized my variable list is so long that I didn't scroll down to the bottom. It is there and it is set to yes. It's entirely possible that the VPN credentials are wrong but that that shouldn't have caused the leak, right? I did test it with IPMagnet after the fact and it's not using the VPN.

Meh crap. Boy did I just screw the pooch. I had an old Docker container that I was fighting with (not working) and gave up on for a while. The other day I decided to manually update the container to try again and didn't bother to look at the documentation. The application seemed to run just fine. When did the container change to allow traffic without the VPN? That just bit me in the ass. 😲 I realize it's all my fault. Like every bit. But the nice thing about this container was that I could trust that nothing could leak out. Using the same environmental variables I had with my old setup I didn't realize I wasn't protected. Before if the VPN didn't work neither did Deluge. I should have checked the new variables since it had been so long. I should have probably tested the connection too. Don't be a dumbass like me. Ugh.