theuema

I am investigating what happend today on my Unraid server, I'd appreciate anyone experienced helping me with this: After realizing that nothing was respondig anymore in the GUI (or any docker service), I tried connecting via. ssh, which was extremely slow but worked somehow. The only thing to get out was the "dead.letter" attached. I don't really understand what caused the Bus errors running the /etc/cron.hourly/user.script.start.hourly.sh script (which just executes /usr/local/emhttp/plugins/user.scripts/startSchedule.php) First guess is simply, that the flash drive just died or a user script file is corrupted somehow? My second guess is that there might be a problem with my mostly self-written user script that I recently updated. What do I do: I backup my flash drive with a custom bash script using the User Scripts plugin. A few days before I realized that, after upgrading Unraid apprently, the *-flash-backup-*.zip file generated by /usr/local/emhttp/webGui/scripts/flash_backup was stored in a different place now. So I updated the script - please see the script attaced! (... I added the cleanup function; introduced the $EMHTTP and $FLASH_BAK_DIR variable). The old version worked great for months... After checking paths and stuff manually I ran the script once. The backup zip file was stored on my nfs drive and everything looked good. So I assumed It is working as intended again. Now, I am not sure if this script may have deleted something that it is not supposed to? But I can't a bug in the bash script. Also the script was scheduled weekly, not hourly or course. I really appreciate anyone having an assumption about what could have happened, or finding a possible bug in my script. I believe there are no logs that I am really able to read out now, right? I did use a flash backup and transfered the key to get my server up again. Thanks! Edit: After running the flash_backup script again, It seems now that the *-flash-backup-*.zip is again stored simply in '/' (like before) I could swear It was stored in /mnt/user/system last week. Still there should not have been deleted anything else at this location running: rm /mnt/user/system/*-flash-backup-*.zip - because the glob pattern is not mathing, right? dead.letter backup_flash_nfs.sh

I ran into an issue recently, when trying to mount a SSD cached share on my Enigma2 Linux receiver permanently, to store my recordings directly onto my unraid server! I use fstab to mount the share (just added nfsvers=4 while investigating the error; not needed): 192.168.178.60:/mnt/user/recordings /media/recordings nfs _netdev,nfsvers=4,rw 0 0 It works till the mover moves the recordings from SSD cache pool into the array. After that i get the following errors on the fstab-mounted nfs share on my receiver: root@dreambox:~$ mount -t nfs 192.168.178.60:/mnt/user/recordings /media/recordings mount.nfs: Stale file handle root@dreambox:~$ rpcinfo -p 192.168.178.60 program vers proto port service 100000 4 tcp 111 portmapper 100000 3 tcp 111 portmapper 100000 2 tcp 111 portmapper 100000 4 udp 111 portmapper 100000 3 udp 111 portmapper 100000 2 udp 111 portmapper 100024 1 udp 34064 status 100024 1 tcp 47303 status 100003 3 tcp 2049 nfs 100003 4 tcp 2049 nfs 100021 1 udp 49947 nlockmgr 100021 3 udp 49947 nlockmgr 100021 4 udp 49947 nlockmgr 100021 1 tcp 41379 nlockmgr 100021 3 tcp 41379 nlockmgr 100021 4 tcp 41379 nlockmgr 100005 1 udp 60889 mountd 100005 1 tcp 50843 mountd 100005 2 udp 33420 mountd 100005 2 tcp 55269 mountd 100005 3 udp 59744 mountd 100005 3 tcp 55475 mountd root@dreambox:~$ showmount -e 192.168.178.60 Export list for 192.168.178.60: /mnt/user/media * /mnt/user/recordings * root@dreambox:~$ ls -l /media/recordings ls: /media/recordings: Stale file handle root@dreambox:~$ showmount -a clnt_create: RPC: Program not registered root@dreambox:/media$ cat /proc/mounts | grep nfs nfsd /proc/fs/nfsd nfsd rw,relatime 0 0 192.168.178.60:/mnt/user/recordings /media/recordings nfs4 rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.178.70,local_lock=none,addr=192.168.178.60 0 0 AFAIK, this can be solved by un-exporting and re-exporting the relevant exports on the server: exportfs -ua exportfs -a and afterwards manually mounting the nfs share on the receiver, mount -t nfs ... But, idk how to schedule this? E.g.: I have several docker containers running, but the mover moves, although I never put them down. I set the daily mover schedule to 05:45, but realized that the other day the mover moved my recordings somewhere around 17:00 (maybe even 17:45 - but there is no AM/PM setting? Therefore, i think this is just a coincidence.). So i can't schedule a cron job for manual mounting my recordings share -> NFS-Shares that must be permanently mounted can not be cached! When deactivating the SSD-Cache and directly using the HDD within my Array it seems to work. Would appreciate the cached solution though.

Hi, I do encounter quite unsatisfying behavior in terms of volatile speeds when copying or moving files from one share to another using rsync. Please view my attached screen recording. In this case, i was copying a 16Gig, or so, file between shares. The source share is located on the same physical HDD than the destination share. Speeds range from <1 MB/s to >200MB/s, always going up and down, like some super-fast cache gets filled up and the HDD can not handle all the incoming data. Does anybody have a better explanation or encounters the same when copying via. ssh/rsync? Screen Recording 2023-02-03 at 18.31.27.mov

After reading this TRaSH Guide (again), I am not very positive that there is a way to achieve a useful location for .nzbget/ that avoids atomic moves other than directly in my media-dl/ (cache_ssd 'Yes' enabled share), like this: - mnt/user/media-dl/ -- .nzbget/ ---- intermediate/ ---- complete/ -- movies/ ---- HD.movies/ -- shows/ ---- TV.shows/ So, I am considering changing the mover script the following way and I hope not to break important stuff here^^ # Check for objects to move from pools to array for POOL in /boot/config/pools/*.cfg ; do for SHAREPATH in /mnt/$(basename "$POOL" .cfg)/*/ ; do SHARE=$(basename "$SHAREPATH") if grep -qs 'shareUseCache="yes"' "/boot/config/shares/${SHARE}.cfg" ; then find "${SHAREPATH%/}" -not \( -path "*.nzbget/*" -prune \) -not \( -path "*.nzbget" -prune \) -depth | /usr/local/sbin/move -d $LOGLEVEL fi done done From testing the initial find command i got the following: root@UNRAID:/mnt/user# find media-dl/ -depth media-dl/.nzbget/test.txt media-dl/.nzbget media-dl/movies/HD.movies/Movie.1.mkv media-dl/movies/HD.movies media-dl/movies media-dl/shows/TV.shows/Show1/S01/Show1.S01E01.mkv media-dl/shows/TV.shows/ media-dl/shows media-dl/.DS_Store media-dl/._.DS_Store media-dl/ Using the new command gives this: media-dl/movies/HD.movies/Movie.1.mkv media-dl/movies/HD.movies media-dl/movies media-dl/shows/TV.shows/Show1/S01/Show1.S01E01.mkv media-dl/shows/TV.shows/ media-dl/shows media-dl/.DS_Store media-dl/._.DS_Store media-dl/ I am not planning to do anything on the "# Check for objects to move from array to pools"-find command some lines below, I hope I don't forget anything here. Please let me know what you think about this solution.

I am new to Unraid, loving it so far, but have quite some trouble now figuring out the best way of caching my media downloads. Share for media downloads (NZBGet) is created from the WebUI, called media-dl. Use cache pool: Yes, so i want to have the mover handling those files on a daily basis. NZBGet uses a folder for intermediate or complete downloads, therefore I set up the following folder structure yesterday: - mnt/user/media-dl/ -- .nzbget/ -- movies/ -- shows/ thinking that Mover will not move directories which begin with a '.' character, but: "Mover will not move any top-level directories which begin with a '.' character" In terms of mounting volumes to my docker container I am not quite sure how to handle this: If I create a directory /mnt/cache_ssd/.nzbget/ it is linked to /mnt/user/.nzbget/ touch /mnt/cache_ssd/.nzbget/test.txt creates the file visible in /mnt/user/.nzbget/ too, since it is essentially a hidden share (? Can't see it in the shares section in WebUI) touch /mnt/user/.nzbget/test2.txt creates the file only visible in /mnt/user/.nzbget/, not in /mnt/cache_ssd/.nzbget/ I believe this is wanted behaviour, because one would need to set 'prefer' or 'Yes' to the share ".nzbget" to actually store a file created in /mnt/user/.nzbget to the cache_ssd pool. So, this is where I'm not sure what is the most performant way to solve this in terms of mounting my docker volumes for NZBGet: I need to have /mnt/user/media-dl/ mounted; everything in media-dl/ is not top-level anymore and is moved, like right now, media-dl/.nzbget/ is moved; -> I need to mount /mnt/user/media-dl/ to have NZBGet categories (or sonarr/radarr) moving it to the appropriate folders (e.g. shows/rome/S01/...) I need to put .nzbget/ to /mnt/cache_ssd/.nzbget/ to prevent the mover seeing it; /mnt/user/.nzbget/ is created, but I can't mount this folder, since it is stored anywhere, but not on the cache_ssd/, where I want the files to be extracted and processed; -> I need to specifically mount /mnt/cache_ssd/.nzbget/ and configure NZBGet accordingly to have tmp, complete and intermediate files there, not seen by the mover. Then it looks like this (remember: media-dl is a cache_ssd 'Yes' enabled share): - mnt/cache_ssd/.nzbget -> mounted to NZBGet docker /nzbget/ - mnt/user/.nzbget -> link directory; essentially a 'hidden share'; this path cannot be used, since it is not configurable in the shares WebUI - mnt/user/media-dl/ -> mounted to NZBGet docker /media-dl/ -- movies/ -- shows/ But here, i have some questions: If I mount it this way, even though both volumes mounted reside on the same physical ssd drive, pool and filesystem (cache_ssd), what would happen if the files are moved from /mnt/cache_ssd/.nzbget/intermediate/ to /mnt/user/media-dl/movies/HD/ ? Does the system actually unneccesarily move the file and not hardlink (or whatever it is called in xfs?) the file in the filesystem? If yes, what is the better solution here?