sohailoo

Members
  • Posts

    54
  • Joined

  • Last visited

sohailoo's Achievements

Rookie

Rookie (2/14)

0

Reputation

  1. does anyone know how can 'i --force-recreate' manually ? where do i run the command for docker compose ?
  2. I've done the guide and replaced the cable to the parity just in case. worked fine for 4 days but today exactly at 2:00 am (syslog time) it happened again and 10-20 containers stopped, i noticed it immediately because i had a tab open of code server and it gave me a message while working that it disconnected tower-diagnostics-20231002-0202.zip
  3. yeah it appears that i have a faulty stick. i replaced the ram and tested it to make sure there's no errors, now i'm getting ton of errors in unraid logs tower-diagnostics-20230926-0123.zip
  4. i got some container that stops like once or twice a day for some reason that i can't figure out. most of these containers are not related to each other in any way, this is the syslog from maybe a minute or two after it happened. ignore all btrfs related issues since i already solved them (changed to xfs), there's also an error for 2 scripts, run.sh and kill.sh. ignore them too since they're not related to the issue (its been happening before i added them) and i already removed those scripts. tower-diagnostics-20230925-0209.zip
  5. checked the ram, nothing wrong with it. i restarted the server and removed the btrfs pool and just made it a one drive xfs pool instead of 2 btrfs. lost around 45gb of data because of some uncorrectable errors. I'll deal with having smaller cache until i get some same size SSDs and moving to zfs with some redundancy.
  6. thanks i managed to pull the diagnostics, i hope it'll help someone figure out the problem. unfortunately, restarting nginx didn't help tower-diagnostics-20230923-2321.zip
  7. i tried to setup a container and it completely froze the GUI while installing it. thankfully i managed to ssh into the server and kill that container, the GUI worked for 10 minutes and froze again. using htop, there's nothing thats taking up resources and the problematic container isn't running ( didn't even manage to complete the installation). how can i diagnose this? is there any way to pull the syslog using cli, because that's the only way i can access the server as of now? my containers are running fine and are accessible on the ip:port
  8. updated to 6.12.4 and that fixed it somehow
  9. i wanted to change my cache drive so i disabled docker to run mover. now i can't access the gui and docker still working (can access containers webui). i really don't want to so an unclean shutdown (i already have a problem with every shutdown no matter what will result in an unclean shutdown). is there anything i can do other than force shutdown the server? i managed to access unraid gui using incognito. there is no docker tab (which is what happens when docker is disabled) but i can still access my containers using their ip. when i try to go to setting>docker the page locks up again. i managed to pull the logs, hope this helps. Edit 1: i rebooted the server, if i start the array with docker disabled the server works fine. as soon as i start docker the system becomes unresponsive and i lose access to the server. tower-syslog-20230921-0438.zip
  10. oh if that's the case, then its not what's happening to me. all the files I'm downloading are completely different in name + size. the only thing that's similar is the path, /data/torrents/seed.
  11. i'm not following. are you saying that if i set the download client to /mnt/user/data/, unraid will download files directly to array even though i set the primary storage for the data share to be the cache pool, secondary storage to the array, and mover action to pool_name --> array? if that's what your saying then this is not whats happening to me. new downloaded files are downloaded to the cache pool and the mover running daily or when 70% full is moving them to the array. i haven't really understood the existing files part so i'll explain how my torrents/folders are structured host path in the torrent container is set to "/mnt/user/data/torrents/" container path is set to "/data/torrents" the torrent client is set to download to "/data/torrents/seed" the "seed" folder has bunch of sub-folders (anime, movies, tv ....). the torrent client creates a new folder for each torrent and put it into one of the sub-folders based on the category hope this helps a little
  12. yes 100% sure. this is the only share that deals with downloads, cache pool is the primary storage and array is the secondary storage with mover action set to ssd_download --> Array. i made sure to double check if it is actually downloading to the cache pool and it sure is. only a couple of containers that download stuff there. all of them are set to download to /mnt/user/data/FolderName
  13. share name: data tower-diagnostics-20230916-1413.zip
  14. if I'm understanding this correctly, "Automatically split any directory as required" which basically means "i don't care even if you put each episode on a different disk" is the best option for me and its already the one all shares use. what about smaller files? if there's a bunch of 20GB files, wouldn't they be written to the disk even if it has less than 100GB? because this is exactly how this drive got filled
  15. all my shares are set to High-water, Automatically split any directory as required, and a 100gb minimum free space. eveything is set to download to the cache ssd and mover takes care of the rest. nothing is set to write directly to shares/disks