manofcolombia

I've been consolidating 2 arrays into 1 by mounting the 2nd arrays drives as unassigned drives and then rcloning the data into the array. This starts off pretty good and I get ~200MB/s writes when using 16 transfers concurrently. These are all large media files so not a ton of itty bitty things happening. After about 10-15 minutes, the same transfer (sometimes on the same files depending on size) will drop to 30-50MB/s. The destination of the copy is all going to 1 drive on the array because of high-water, but it still started off fine at ~200MB/s and it just progressively gets slower till it stabilizes at 30-50MB/s. The destination of the copy is not going to any cache pool so its not like its filling cache and then switching to array. I also noticed this with my parity checks. At the beginning of the parity check, its flying at ~200+MB/s and then by the end the average is ~50MB/s and its taken ~3 days. I thought maybe it was drive bay or HBA cable, but I swapped drive bays today and still seeing the same behavior. Cache is already being used for vms and docker so its not like there are competing writes from those. stylophora-diagnostics-20240108-1422.zip

Thanks for the confirmation to set my mind at ease!

Hey @ich777 I was pointed in your direction for this question: I'm currently still running 6.8.2 with the old linuxserver nvidia build. I'm looking to finally upgrade to meet the latest stable unraid, however, in the past, I've always reverted back to the vanilla build before upgrading. The old plugin no longer works/supported so I am curious if you would suggest trying to get my hands on a vanilla build of 6.8.2 before attempting to upgrade to 6.11 and/or any other gotchas you might think of regarding my current situation? Thanks

Needless to say, its been quite a long time since I've upgraded unraid... I am curious if anyone has done such a big jump in versions or if it is suggested to upgrade in smaller steps. The thing I am most worried about is that I am still running an old nvidia build from @linuxserver.io and I can no longer revert back to the stock image (easily?) to do a more vanilla upgrade.

All good man. Stuff happens. Thanks for taking a look. I confirmed that the lastest build is working as it used to and the db and related files is now being written out to my volume mount. Thanks

@Stark any luck? Container restarted again and all its config is gone again

Within the last 2 weeks, I started having issues with the hosts/schedules being wiped after restarting/updating the container. The only log that seemed interesting is this: 2019-03-03 15:03:13.506 - INFO - [DavosApplication] - No active profile set, falling back to default profiles: default Assuming that the config isn't being saved to persistent location so it goes back to a default state. I removed the image and all appdata to start over and found that the container does appear to write its persistent data to /config (mapping) anymore. Based on the last log message I have written to volume mapping, this started on 2/10

Running into this and I believe it is causing some movies to be constantly missing, even though they are local to the box where radarr lives: Import failed, path does not exist or is not accessible by Radarr: /home/hd3/manofcolombia/torrents/data/The.Butterfly.Effect.2004.DC.1080p.BluRay.H264.AAC-RARBG My workflow goes like this: Ombi -> radarr -> deluge on seedbox -> filebot on seedbox renames and moves to movies folder on seedbox -> davos sftp seedbox movie folder to on prem movie folder -> Plex scans and imports. The above file path is the file path is the path for deluge downloads on the seedbox so I assume deluge is sending back the path. How do I go about handling this without leaving a ton of data on the seedbox, and without being able to mount the seedbox path into the radarr container on prem.

Yea that hasn't happened before. May have been a one off kind of deal.

Still dies at some point after heavy use. But there are no more timeouts in the logs. stylophora-diagnostics-20190102-0651.zip

Just got it happening a couple of times since I tested. But it was literally just happening. Here are the fresh diagnostics The worst thing is, I start getting crazy cpu_io_wait, assuming because plex container expects the path to be there but the path isn't happy. So what I end up having to do is: 1. stop plex - because it normally won't remount if its still running and it'll give me a blank error reason 2. Unmount the share which works sometimes on the first try but can take 30-45+ seconds for the plugin to say its actually unmounted - also sometimes does not work on the first try 2a. Start plex if I don't feel like dealing with #3 and back to normal 3. Mount the NFS share again, very rarely works on the first try 4. Start plex once the share is mounted successfully again stylophora-diagnostics-20181231-1834.zip

Testing it now. Set the share up as a separate library so the setup should be identical now.

Try this then. It should be in there. I see the logs of it not responding. stylophora-diagnostics-20181230-1314.zip

I ended up moving the entire library to my storage for the time being, but I'll get diagnostics for 6.6.6. I thought I had attached them but it was just the log snippets - shame on me. Actually, @dlandon how far back will diagnostics go? Will they survive a reboot of the host?

Unraid 6.6.6 I have been having issues with an NSF mount that seems to unmount/stop responding in the middle of the night. At first I thought it was SMB being weird so I switched over to NFS, but I am still having the same issue. This drive is mounted with no special scripting. The drive holds a music library that is then mapped to a plex container. At somepoint, normally in the middle of the night, but it has happened a couple of times during the day and even during active use of the drive, music ceases to be playable. The gui for unassigned devices shows a zero byte counter and I have to unmount and attempt to remount it a couple of times before it mounts successfully again. I don't really get any "useful" logs around the time that I believe the issue happens on either side. The NFS share is on a vm on another host "locally" - logically anyway. Its being accessed over IPsec tunnel that shares other resources. I have confirmed that the tunnel is constantly up and doesn't go down during the time of the issue. Here are some of the logs I get in unraid when its already broken: Dec 13 03:11:18 stylophora kernel: nfs: server 192.168.130.4 not responding, still trying Dec 13 03:11:18 stylophora kernel: nfs: server 192.168.130.4 not responding, still trying Dec 13 03:11:18 stylophora kernel: nfs: server 192.168.130.4 not responding, still trying Dec 13 03:11:18 stylophora kernel: nfs: server 192.168.130.4 OK Dec 13 03:11:19 stylophora kernel: nfs: server 192.168.130.4 OK Dec 13 03:11:21 stylophora kernel: nfs: server 192.168.130.4 OK This happens over and over until I fix it. This is me fixing it hours later when I find that its broken - with a couple of failed attempts: Dec 13 08:08:01 stylophora unassigned.devices: Removing Remote SMB share '192.168.130.4://mnt/music/library'... Dec 13 08:08:01 stylophora unassigned.devices: Unmounting Remote SMB Share '192.168.130.4://mnt/music/library'... Dec 13 08:08:01 stylophora unassigned.devices: Unmounting '192.168.130.4://mnt/music/library'... Dec 13 08:08:01 stylophora unassigned.devices: Unmount cmd: /bin/umount '192.168.130.4://mnt/music/library' 2>&1 Dec 13 08:08:03 stylophora unassigned.devices: Unmount of '192.168.130.4://mnt/music/library' failed. Error message: umount.nfs: /mnt/disks/cruton-music: device is busy Dec 13 08:08:29 stylophora unassigned.devices: Since there aren't open files, will force unmount. Dec 13 08:08:29 stylophora unassigned.devices: Unmounting '192.168.130.4://mnt/music/library'... Dec 13 08:08:29 stylophora unassigned.devices: Unmount cmd: /bin/umount -f -l '192.168.130.4://mnt/music/library' 2>&1 Dec 13 08:08:29 stylophora unassigned.devices: Successfully unmounted '192.168.130.4://mnt/music/library' Dec 13 08:08:29 stylophora unassigned.devices: Removing SMB share file '/etc/samba/unassigned-shares/cruton-music.conf' Dec 13 08:08:29 stylophora unassigned.devices: Removing SMB share definitions from '/boot/config/smb-extra.conf' Dec 13 08:08:29 stylophora unassigned.devices: Reloading Samba configuration.. Dec 13 08:08:29 stylophora unassigned.devices: Successfully removed SMB share 'cruton-music'. Dec 13 08:08:29 stylophora unassigned.devices: Share '192.168.130.4://mnt/music/library' unmount successfull. Dec 13 08:09:05 stylophora rpcbind[12310]: connect from 127.0.0.1 to getport/addr(status) Dec 13 08:09:25 stylophora unassigned.devices: Mount SMB/NFS command: mount -t nfs -o defaults '192.168.130.4://mnt/music/library' '/mnt/disks/cruton-music' Dec 13 08:09:25 stylophora unassigned.devices: Mount of '192.168.130.4://mnt/music/library' failed. Error message: Dec 13 08:09:31 stylophora emhttpd: req (2): csrf_token=****************&title=System+Log&cmd=%2FwebGui%2Fscripts%2Ftail_log&arg1=syslog Dec 13 08:09:31 stylophora emhttpd: cmd: /usr/local/emhttp/plugins/dynamix/scripts/tail_log syslog Dec 13 08:10:28 stylophora rpcbind[15718]: connect from 127.0.0.1 to getport/addr(status) Dec 13 08:10:28 stylophora unassigned.devices: Mount SMB/NFS command: mount -t nfs -o defaults '192.168.130.4://mnt/music/library' '/mnt/disks/cruton-music' Dec 13 08:10:28 stylophora unassigned.devices: Successfully mounted '192.168.130.4://mnt/music/library' on '/mnt/disks/cruton-music'. Dec 13 08:10:28 stylophora unassigned.devices: Defining share 'cruton-music' with file '/etc/samba/unassigned-shares/cruton-music.conf' Dec 13 08:10:28 stylophora unassigned.devices: Adding share 'cruton-music' to '/boot/config/smb-extra.conf' Dec 13 08:10:28 stylophora unassigned.devices: Reloading Samba configuration... Dec 13 08:10:28 stylophora unassigned.devices: Directory '/mnt/disks/cruton-music' shared successfully. On the share side, I don't see any useful logs other than me remounting it.

Behind nginx in a separate VM. This nginx instance provides all my reverse proxy needs and certs to all my other services, but going directly to the ip:port should still yield the webgui for the container unless unraid is also using 8443, correct? Based on my nmap, with my container on and off, it looks like unraid is not using 8443 unless my container is on. So I don't get why I'm still hitting the unraid gui instead of the container on that port. EDIT: I fixed it. Even though I was going to the ip:port where the container was, I believe reverse dns lookup was kicking in. When it kicked it, my internal dns would direct me to my nginx instance which still had my proxy pass set to 443. So I was getting pushed back to the unraid gui on 443. Sorry for the trouble. It was just DNS trying to be helpful...

I did that as well as I thought it was my internal DNS. https://<unraid-ip>:8443 This still redirects me to the unraid gui. Can you elaborate as to why rebooting would help the situation since I would think that restarting the container would be enough. Edit: I also changed the WebUI in the template to accommodate my changes as well, still no joy. https://[IP]:[PORT:8443]/

After 6.4 update, unable to reach nextcloud gui. I get redirected to unraids gui. I figured this was because I was using 443 on the host side of the container before the update. So I changed my host port to 8443 and left the container port as 443, since that is where the service is running. This still redirects me to the unraid gui instead of nextcloud. Tried a different browser in case it was cached.

Noticed an abnormally high cpu usage from CP today. I looked and the app was working fine and didn't appear to be doing much or searching, but then I looked at the container logs and found this over and over: Traceback (most recent call last): File "/app/couchpotato/CouchPotato.py", line 135, in <module> l.run() File "/app/couchpotato/CouchPotato.py", line 89, in run runCouchPotato(self.options, base_path, sys.argv[1:], data_dir = self.data_dir, log_dir = self.log_dir, Env = Env) File "/app/couchpotato/couchpotato/runner.py", line 353, in runCouchPotato server.listen(config['port'], config['host']) File "/app/couchpotato/libs/tornado/tcpserver.py", line 125, in listen sockets = bind_sockets(port, address=address) File "/app/couchpotato/libs/tornado/netutil.py", line 145, in bind_sockets sock.bind(sockaddr) File "/usr/lib/python2.7/socket.py", line 228, in meth return getattr(self._sock,name)(*args) socket.error: [Errno 98] Address in use Restarted the container has fixed the issue for now, but thought I would give the devs a heads up and potentially look into a cause for this issue.