Froberg

Okay, I did some cleanup and appdata folder is now moved to a cache drive instead. I've set the TRANSMISSION_UMASK setting at 000 and that does get replicated in the settings.json file. (Anything entered manually gets removed on restart..) It still sets permissions to this when looking at the log during bootup; Generating transmission settings.json from env variables sed'ing True to true Enforcing ownership on transmission config directories Applying permissions to transmission config directories Setting owner for transmission paths to 99:100 Setting permission for files (644) and directories (755) umask value is 0 in settings.json - chaned from "2". No change. So what's setting the permissions? 🙂

Hi man, thanks for responding. Looking at the directory structures, I just realized that the data folder specified is the actual transmission application data. I'll move that now and check around for further settings. I was unaware that changes to settings.json would be persistent.. But it seems like the docker is setting the file permissions even before transmission is started, effectively making me unable to use the share from another workstation over SMB. If you look at the log while starting it up, you'll see the same behaviour I'm sure. Is it a byproduct of privileged access and thus not something that can be avoided? I mean, it'll be a bit more to manage, but I figure I can work around it.. but it's been very insistent about not even loading anything I manually put in to the watch directory even after setting permissions manually too. It's a bit odd. Anyway, I'll test out some more on my end and see if I can learn something. Thanks again.

Hi all Finally decided it was time for VPN and set up this wonderful docker. Everything is working flawlessly using PIA, except for some permissions weirdness. I'm not used to transmission taking control of all files and folders so forcefully. As in, I can't even use my watch directory because of it. Can anything be done to facilitate this? Medusa hasn't run yet, but I'm betting that stuff like unpacking will become problematic as well. Edit: I've fiddled about some more with UMASK mentioned on the previous page with no luck. Here's what it's setting in the log for the docker: Enforcing ownership on transmission config directories Applying permissions to transmission config directories Setting owner for transmission paths to 99:100 Setting permission for files (644) and directories (755) Basically I want to be able to use my watch folder via SMB share and for stuff like Medusa to be able to move stuff around. Nothing too fancy. I have it set up very neatly with a regular transmission container. Is there any reason that this particular instance has to play naughty with the permissions? Is it to do with privileged access mode? If I disable that, it won't run at all.

I've used Resilio way back to sync my data from my primary box to a secondary NAS. I've recently purchased a SOC motherboard and set up another home NAS to replicate this. Unfortunately, resilio seems content to sit at around 120mb/s. If I disable tracker options and set it to use LAN only, it does nothing. I've tried fiddling with the power user settings, encryption to see if that was the overhead and whatever else I can think of. Any ideas? Both boxes have dual gigabit NICs and should be able to at least get gigabit for the transfers. It will get there.. eventually.. of course, but the idea was to turn on the backup box for a few days a month to get synced and to run a parity check and otherwise keep it spun down. Any suggestions as to where I might be wise to look? They're both set to bridge on the respective docker containers, would host maybe have an impact? Solved it myself; Setting the share on the receiving box to forced LAN and changing the docker containers on both sides to host mode proved to drastically increase speed.

Just to chime in, I just tried the tool on both a verbatim and a kingston USB device, 4 and 16 gigs respectively. Both failed. The Verbatim one even had weird chinese character write errors. Formatted it manually, named it UNRAID & ran the manual setup, worked without a hitch on the Verbatim that I actually wanted to use. The download page needs some work, as there are no instructions available for the manual setup... and as it stands, it kinda feels like the "tool" offering is causing more of a problem than a benefit to new people.

Came here for this.. Running nginx proxy manager to serve nextcloud.. do I need to take any action other than update when available? I'd rather not mess around with the core config files. I guess I can always take it offline until a fix is available.

Try forcing SSL for a start.

Maybe try reverting the config to a default one. I haven't had much experience with setting up alternate networks but it seems the 502 Bad Gateway is connected to nginx proxy manager being unable to route to the docker you want - as per the post directly above yours. I'd start with a fresh config if I were you, and make sure to clean up the appdata so you don't just get the old config back. I can't see anything in your settings that would explain it. Maybe someone else can spot it though, as I'm far from an expert.

What's with the trusted_proxies line?

I have not seen that message. I've attached my https setup for reference. Is yours set up similarly?

Glad you got it sorted.

As I set this up a few months ago I might actually be of use here. Assuming you set up the proxy-part correctly, maybe you're missing some steps in the owncloud config. (i.e. forcing https, maybe..) Check your config.pgp and ensure the following lines are present: 'overwrite.cli.url' => 'your.domain.goes.here', 'overwritehost' => 'your.domain.goes.here', 'overwriteprotocol' => 'https', (substitute your own domain, of course.) You also need to make sure that the Nginx Proxy Manager and the NextCloud container is on the same ip address.

NAT loopback brought me in the right direction; https://community.linksys.com/t5/Wireless-Routers/WRT1900AC-NAT-Loopback/m-p/1013735/highlight/true#M318597 That did it. It's extremely slow, for some reason, but it did the trick! Thank you so much. Now to figure out why it's so slow..

First of; this is a brilliant piece of work. The last time I had to set up proxying on nginx it was on an ubuntu box and it was a huge hassle. This has worked so flawlessly and I applaud the effort! I'm hoping you can help me solve one remaining issue, however. This evening I've set up; MariaDB NextCloud NGINX proxy Manager To do; some web-server running a simple CMS. I got NextCloud to work using my own subdomain at cloud.mydomain.com, unfortunately I lost all access to it internally upon doing so. I know it's to do with reverse proxying and the only workaround I had back in the day was to manually edit my host file. Unfortunately, since the nextcloud container sits on the same network as UnRaid it's not at 443 but 444, essentially I can only access UnRaid and not the NextCloud installation from inside the network. Is there any way I can resolve this using this container, or do I need to look elsewhere? I'd like to 'fix' it for my entire network this time, as I plan to be using multiple mobile apps and get the wife syncing, too. I'm just hoping for a miracle, really. Considering I am going to be adding a website, and probably some other stuff, it would be nice to be able to access it internally, too. Cheers, if anyone has some insight to share.

Ah, that makes sense. Thanks for explaining it even though it's not a NextCloud issue. I'll give that a whirl, cheers.

Hi So I'm a year overdue for re-working some of my old setup prior to going UnRaid and I'm seemingly a bit stuck. I've set up MariaDB and configured a nextcloud user, database and password. MariaDB is set up to run on the Unraid server primary IP. Nextcloud has been set up with a dedicated IP. Unfortunately, I can't seem to connect. Initially I got a DB password error, which I sussed down to be caused by an old password being present in the cache, since removed. However, when I try to connect to the database from nextcloud I get the following; Do I need to do something specifically for the MariaDB or for the NextCloud container for them to be able to communicate? I've tried searching, but all guides I've found don't have them running on separate IP's, and I really adore that feature. Cheers for any help that can be provided here..

This app is amazing. Thank you so much. Really a shame you depreciated it because of dimwits..

+1 for the linuxserver option.

I was today years old when I found out the docker page had an advanced view switch. Cheers mate.

So, ah, like this? Or am I missing something? Wouldn't be the first time.

Anyone else experience memory leakage? I've had two instances now, half a year apart, of Medusa eating up all available system memory, prompting me to restart it to restore system functionality. Can I limit the containers memory usage, or is this a known bug? Cheers.

A memory leak usually presents itself as memory usage steadily increasing over time. It's down to a programming mistake usually, so I'd gather log files and send them to the resilio people. Maybe the docker container manager. If it's acting as I described. Alternatively live with it and have it reboot the container at regular intervals via scripting - but it does sound like you're describing a memory leak. It sounds like it's not unloading data as it handles it.

Sounds like a memory leak to me, Lenny.

I set mine up like this. (see attached) You can always add another host path for more folders.

Updated from 6.6.3 to 6.6.6. No issues. Also: \m/