Dyon

Members
  • Posts

    118
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Dyon's Achievements

Apprentice

Apprentice (3/14)

34

Reputation

  1. Well, that explains a lot! Glad you found the issue. If you ever run into problems again, let me know!
  2. That is really strange. As a test, I mounted my STACK in Windows, added a file, and a few moments later it did appear in the STACK folder on my Unraid. So it works for me... There are two things you can do. 1: Check the logs. Set the SILENCE_OUTPUT of the container temporary to "0". This will spam the container log, and not everything would be readable because of that. At the bottom of the spam, error should/could show up. (I haven't implemented something to output the log somewhere, might do that soon though, since it won't be a lot of effort) 2: Start Fresh. There could be an underlying problem that isn't easily visibele. Yes, you would need to redownload/resync everything with Unraid again. Stop the container. As long as the container is stopped, there is no risk in removing the folder. Remove the folder /mnt/user/data/Ralf/Stack/ from your Unraid. Start the container again, the folder should get created automatically.
  3. Edit this Docker Container in Unraid, set the WEBUI_PORT environment variable to something else. Start the container. You should now be able to access it to the port you did set.
  4. As far as I know (for my own experience), owncloud works sequential. So it will download all files first, when that is finished it will start the upload. So, you are saying if you upload a file via the STACK PC Client, it doesn't show up in the Unraid folder? Does it appear on the STACK website? Because I can't imagine it wouldn't sync that file
  5. I don't see anything wrong with the other environment variables that you have set. Mine are exactly the same (I also use STACK) Since using "/TTD" works for you, I don't think it's a OC_PASS problem, so I assume you are already using the WebDav App Token from STACK. I suspect there might be a problem with the database that OwnCloud stores for synchronisation, since you switched from "/TTD" to "/" it might have gotten confused. What I would do it: Stop the container. As long as the container is stopped, there is no risk in removing the folder. Remove the folder /mnt/user/data/Ralf/Stack/ from your Unraid. Start the container again, the folder should get created automatically. Edit: These are my environment variables: OC_USER username OC_PASS webdav_app_token OC_SERVER my_ulr_for_stack.stackstorage.com OC_URLPATH / OC_FILEPATH / RUN_UID 1000 RUN_GID 100 TRUST_SELFSIGN 0 Sync Location /mnt/user/STACK/dyonr/ OC_WEBDAV remote.php/webdav OC_PROTO https SYNC_HIDDEN 0 SILENCE_OUTPUT 1 RUN_INTERVAL 30
  6. Your OC_WEBDAV path is incorrect for TransIP Stack, in Unraid edit the owncloud-client docker, and expand the advanced settings at the bottom and set OC_WEBDAV to this (without quotes): "remote.php/webdav" Edit: Nevermind, yours is set correctly. Change the: OC_URLPATH: /owncloud/ to: OC_URLPATH: /
  7. I've worked on a fix for the problem mentioned by @howyoulikethat, but while working on it, I've decided not to release this. I do not want to mess with the config file of users. The code below was intended to be a new section of the qBittorrent/start.sh file, to fix the config. Problems; 1a. It doesn't check if the user already fixed it themselves. 1b. It doesn't check the [BitTorrent] section in the config file to see if the new Session\DefaultSavePath etc already exist, so it keeps adding it on every reboot. 2. Moving the files is a dirty fix. 3. Messing with the .fastresume files is tricky. What if someone has a rule to automatically move it to a sub-directory? In that case the .fastresume file would be different than the default savePath29 / save_path29.
  8. It seems like qBittorrent changed something that made the config different. I'll see if I can pushg a new update soon to fix this for everyone using this container. For now; 1. Open qBittorrent 2. Go to settings 3. In the first default tab (Downloads) change the 'Default Save Path' to '/downloads'.
  9. Disabling SSL is indeed bugged at the moment. I will fix this in a future update. For now, if you want to disable SSL: - Stop the container - Set the environment variable ENABLE_SSL to 'no' - Go to the Unraid Appdata of this Docker container, appdata/qBittorrent/config/qBittorrent.conf Set 'WebUI\HTTPS\Enabled=true' to 'WebUI\HTTPS\Enabled=false' Want to reset the password? In the same config file set 'WebUI\Username' as 'WebUI\Username=admin' Remove the line 'WebUI\Password_PBKDF2' and replace it with this line: WebUI\Password_PBKDF2="@ByteArray(ARQ77eY1NUZaQsuDHbIMCA==:0WMRkYTUWVT9wVvdDtHAjU9b3b7uB8NR1Gur2hmQCvCDpm39Q+PsJRJPaCU51dEiz+dTzh8qbPsL8WkFljQYFQ==)" After that, stop and start the container. Note that having SSL disabled COULD cause login issues.
  10. On my own system, I was never able to confirm DNS leakage. I tested it on 3 containers, my own 'docker-passthroughvpn', 'binhex/arch-mineos-node' and 'ich777/teamspeak', all giving me the same results. My results (37.xxx.xxx.xxx is my VPN IP): root@6cb7b6696c1d:/tmp# ./dnsleaktest.sh Your IP: 37.xxx.xxx.xxx [Netherlands, AS9009 M247 Ltd] You use 4 DNS servers: 141.101.64.196 [Netherlands, AS13335 CloudFlare Inc] 141.101.64.197 [Netherlands, AS13335 CloudFlare Inc] 141.101.75.126 [Netherlands, AS13335 CloudFlare Inc] 141.101.75.147 [Netherlands, AS13335 CloudFlare Inc] Conclusion: DNS may be leaking. root@6cb7b6696c1d:/tmp# While running it on Unraid itself yields a different result, showing my actual IP addresses root@Dyon-unRAID:/tmp# ./dnsleaktest.sh Your IP: 2001:xxxx:xxx:xxxx:xxxx:xxxx:xxxx:xxxx [Netherlands AS33915 Vodafone Libertel B.V.] You use 2 DNS servers: 94.xx.xx.xx [Netherlands AS33915 Vodafone Libertel B.V.] 2001:xxxx:xxxx:x:xxxx:xxxx:xxxx:xxxx [Netherlands AS33915 Vodafone Libertel B.V.] Conclusion: DNS is not leaking. It's hard for me to look into an issues that I can't replicate obviously. Could you share the log of your passthroughvpn container? Obviously, don't forget to mask out any sensitive information like IP-addresses, but keep them so that I can tell them apart. You can also open a console to the container and "cat /etc/resolv.conf". In there for me, it also lists the local IP of my router. What you can try is to install vi(m) and remove the line of your router to see if that fixes it maybe. If that's the case, I'll look into fixing that.
  11. Just delete the '._' one. Should be fine. The .DS_Store, ._.DS_Store and ._melbourne.ovpn are created because you use a Mac. If you open or edit files in there these files will be generated. If I work on an update for the container, I'll try to add something to ignore those files. But for now, just delete any ._ files in there.
  12. Try changing the filename from `._aus_melbourne-aes-128-cbc-udp-dns.ovpn` to `aus_melbourne-aes-128-cbc-udp-dns.ovpn` (remove the . and _ in front of it) and try again. Or just rename it to something like 'melbourne.ovpn'.
  13. They finally released an update after more than two years? 🤡 Anyhow, the container is updating, should be up in max. 10 minutes after me posting this message
  14. Did you alter the script in any way? Did you change the name of the passthroughvpn container? Could you go to your 'Docker' tab in unraid and check that the name of the passthroughvpn container is literally 'passthroughvpn' (no difference in capitalization) And then check if the script matches this on the 4th line where it says 'PASSTHROUGHVPNNAME=passthroughvpn' This error seems to be caused by a wrong container name, or wrong name in the script.
  15. No, you should use your full subnet, for example 192.168.178.0/24. I think that would fix your issues. Let me know what does and doesn't work after changing that.