• Content Count

  • Joined

  • Last visited

Community Reputation

5 Neutral

About Bob1215

  • Rank


  • Location
    Midwest, USA

Recent Profile Visitors

474 profile views
  1. - I tried both Host and Bridge, and they both worked for me. - causes the container to succeed in creation, but fails to start (and no logs) - worked perfectly - I copied a different container and put `http://[IP]:[PORT:631]/`, which works! I have an HP printer connected by USB (with Parallel Port to USB cable) that I cannot get CUPS to see. Some basic info: root@Tower:~# lsusb Bus 002 Device 003: ID 0781:5575 SanDisk Corp. Cruzer Glide Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 008 Device 001: ID 1d6b:0001 Linux F
  2. I'm using a subdomain like "". I originally attempted to update by connecting remotely via a VPN connection to my server and applying the update through the webui. Not sure if that contributed to the 504s. I'll keep a closer eye on the update process and report back if I have any useful information for troubleshooting/debugging.
  3. If you still needed to complete the update: Click the link to the update guide in the first post, skip step 2 (putting nextcloud into maintenance mode with occ), complete the steps to update manually and close maintenance mode. Otherwise just do the last steps in that guide to close maintenance mode. Sent from my SM-N950U using Tapatalk
  4. Has anyone experienced this and were able to solve it?
  5. I kept getting 504 codes at different points in the web updater sequence, and at another time some message about not being able to unzip/zip. But I did just skip that second step regarding turning maintenance mode on (like you said, it was already stuck on). I completed the steps in the guide and it's back up and running. Thanks for taking the time to help out [emoji4]
  6. I attempted to follow the guide linked in the first post, but it my `occ` is missing root@Tower:~# docker exec -it nextcloud bash root@7010b1d5296c:/# sudo -u abc php7 /config/www/nextcloud/occ maintenance:mode --on Could not open input file: /config/www/nextcloud/occ root@7010b1d5296c:/# ls -l /config/www/nextcloud/ total 16 drwxrwxr-x 1 abc abc 0 Jan 10 17:17 apps drwxrwxr-x 1 abc abc 38 Jan 10 17:17 config -rw-rw-r-- 1 abc abc 57 Jan 10 17:16 index.php -rw-rw-r-- 1 abc abc 57 Jan 10 17:16 public.php -rw-rw-r-- 1 abc abc 57 Jan 10 17:16 remote.php -rw-rw-r-- 1 abc abc 57 Jan 10
  7. I kept getting a 504 code when attempting to update form the webUI. Now I can't access nextcloud at all. I posted and issue here Expected Behavior When navigating to the NextCloud instance through the web browser, the application should be shown. Current Behavior The following message is shown "Update in process." and has persisted for multiple hours, including after reboot and using multiple browsers (FireFox ESR and Brave Browser) Steps to Reproduce 1. Open web browser 2. Type in NextCloud URL 3. See message Environment OS: unR
  8. I can't speak to your other questions, but I've read quite a bit on this forum and other forums about the number of torrents that are able to be seeded. It seems like most torrent clients start to have issues after 3,000 or so (some as few as a couple hundred). Many people mentioned that in order to get the 35k+ torrents work, you'd be using rTorrent in a terminal, as even ruTorrent seems to max out around 4-5,000. Others can correct me if I have misunderstood this, though.
  9. I'm having the same issue, and same log output: "[warn] Wait for rTorrent process to start aborted, too many retries"
  10. For the first time in a while, when I clicked on the Dev Pack, it loaded instantly... It may have been due to the solution in the reddit post?
  11. I'm on 6.8.0 and mine hangs with the same message. I found a reddit post where someone had a similar issue, and the suggestion in the post worked for them. Unfortunately, it hasn't worked for me. Any advice is welcome.
  12. Yeah, if you're looking for the quassel-web thread, it can be found here: So, I'm not quite sure how these linuxserver proxy-conf files work, but here is my attempt at creating one for quassel-core: server { listen 443 ssl; listen [::]:443 ssl; server_name quassel.*; include /config/nginx/ssl.conf; client_max_body_size 0; location / { include /config/nginx/proxy.conf; resolver valid=30s; set $upstream_quassel_core quassel-core; proxy_pass http://$upstream_quassel_core:4242; } }
  13. I'm trying to do this now, but no luck so far. I've copied the `quassel-web.subdomain.conf` to `quassel-core.subdomain.conf` in `/mnt/user/appdata/letsencrypt/nginx/proxy-confs` and edited the upstream, but have not been able to connect, yet.
  14. Try following the guide I posted here, and report back if it works again. Because you mentioned that you don't have issues using this container with public trackers, this is more of a specific tracker issue, than a container issue. I would seriously consider reaching out to your tracker.
  15. Maybe @binhex can weigh-in. But I wanted to clarify: You are using the latest version of this container. Which is 2.0.3_23_g5f1eada3e-1-01 (shows as 2.0.4.dev20)? Your tracker does not have this version whitelisted? Your tracker was still somehow allowing you to connect, even though you were using an unsupported download client? Now you can no longer connect with this unsupported download client? If that is the case, I would think the issue is your tracker patched the bug that was allowing unsupported clients to connect. I would suggest reaching out