robobub

Members
  • Content Count

    39
  • Joined

  • Last visited

Community Reputation

3 Neutral

About robobub

  • Rank
    Newbie

Recent Profile Visitors

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

  1. Anyone familiar with this cert renewal error? I set it up how I interpreted spaceinvaderone's video, which had subdomains as the separate variable from the dns provider that I don't own. The description though seems to imply putting the subdomain.provider.com as one variable under domain name. Which is correct? Despite this error, the reverse proxy still ended up working, with a cert error.
  2. Does anyone have an issue with public access / downloads not showing up in the activity tab? I have a public password protected photo share set up using reverse proxy with swag and nothing shows up under activity (or under individual file activity). I can however look at swag's nginx logs, though it's difficult to find out what url represents what file. Using the latest linuxserver/nextcloud docker nexcloud 19.0.4 activity 2.12.1 unraid 6.8.3
  3. My parity check isn't resuming with all drives classified as cool. Any ideas? Sep 5 16:45:01 tower parity.check.tuning.php: DEBUG: -----------MONITOR start------ Sep 5 16:45:01 tower parity.check.tuning.php: DEBUG: Parity check appears to be paused Sep 5 16:45:01 tower parity.check.tuning.php: TESTING: parity temp=43 (settings are: hot=47, cool=43)) Sep 5 16:45:01 tower parity.check.tuning.php: TESTING: disk1 temp=42 (settings are: hot=47, cool=43)) Sep 5 16:45:01 tower parity.check.tuning.php: TESTING: disk2 temp=39 (settings are: hot=47, cool=43)) Sep 5 16:45:01 tower parity
  4. I never realized I could change this, I did have this left at the default 24. Not a problem at all, it's a low priority issue and the plugin otherwise works great. Thanks!
  5. I noticed my cache read speeds were quite slow and did some investigation. I had recently switched from btrfs-encrypted cache to xfs-encrypted cache due. It seems that on my system my read speeds with xfs/reiserfs encrypted cache are extremely slow, while unencrypted or btrfs-encrypted is much faster. Any ideas what could be going on? Anyone else have this issue? reiserfs-encrypted 130 MB/s write 25 MB/s read xfs-encrypted 130 MB/s write 20 MB/s read xfs-unencrypted 200 MB/s write 450 MB/s read btrf
  6. How is the temperature-based pausing and resuming of the parity check supposed to work? It seems like it ran through the entire time without pausing even though the debug messages clearly show drives were hot. It does appear that the scheduled resume happened with all drives already hot/warm, does it only pause if a cool drive transitions to warm/hot? Perhaps there should be a check whether to start in the first place with the current temperature: some days are hot and it pushes them into the warm zone and the check shouldn't run at all. Here is a log with the scheduled
  7. Using android here, might be a different issue in my case? Also, for me, it works without letsencrypt reverse proxy (on LAN) and fails with letsencrypt reverse proxy (still on LAN, same upload speed)
  8. Having an issue uploading large files to nextcloud only using letsencrypt reverse proxy, works fine without letsencrypt. Even just a 2.3 GB file: the file completes uploading on the client, and I see that it's processing and copying the file into the final location on nextcloud/<user>/files/<path>. However, this only lasts for around 1 minute then stops writing the file, and tells the client that it timed out. Watching the file get written, it's in the range of 800~1200 MB. If I turn reverse proxy off and revert those settings, it works fine and the "processing" of c
  9. Ah, with a new share the issue doesn't exist. The issue is caused by using any form of btrfs compression on the disk. Please see if you can reproduce: ## no compression, no issue root@Tower:/mnt/user/test# rm -rf /mnt/user/test/1; root@Tower:/mnt/user/test# rm -rf /mnt/cache/test/1 # should be no-op, but just in case root@Tower:/mnt/user/test# cd /mnt/disk1/test root@Tower:/mnt/disk1/test# v total 0 root@Tower:/mnt/disk1/test# btrfs property get . root@Tower:/mnt/disk1/test# ## no compression, no issue root@Tower:/mnt/disk1/test# mkdir -p 1/2/3 root@Tower:/mnt/disk1/test# cd /mn
  10. With Btrfs-encrypted array disks and xfs-encrypted cache disk? Any diagnostic recommendations on my end?
  11. You can see what is launching that find process by going up a few lines: dynamic cache dirs plugin. Add your external hard drive to the excluded folders path of that folder caching plugin
  12. Something is scanning your /mnt/disks/Seagate_Backup_Plus_Drive with the command find with PID 25568 (the 2nd column in your screenshot, PID) This doesn't show up on your diagnostics what process it is and what spawned it. You can try to trace what was running by running ps axjf | egrep 25568 The first 4 columns will list other processes associated with it, so then you add that to the egrep command. If any of the columns are 0,1,2, I would exclude it as it is one of the root processes. ps axjf | egrep '25568|<column 1>|<column2>|<column 3&g
  13. I don't have your exact situation, so I'm not guaranteeing it will fix it. But it takes 1 second to try, and you can always change it back (you can just cat that same location to see what it was before changing). It is a bit odd that it goes up without starting any copying. I would look to see if something is scanning it (e.g. iotop+lsof, or a fancier tool)
  14. Okay? Your USB drive will have a device ID, and you can change the I/O Scheduler and Queue size for that device. I suggested changing both the source and destination drives. Not that it's too relevant, but the post I linked was moving data from the array to the cache drive. My suggestion applies with any data transfer. It's a simple test that has a chance of helping.