AgentXXL

But as I and others have mentioned, even using a SSD as an unassigned device experiences the same issue. I do believe it's the Plex client(s) at fault more than Mover.

I've experienced this as well. I've tried using a SSD as an unassigned device for Plex, and also on my SSD cache drive within unRAID. I do believe that part of the problem is the Plex clients themselves and will be reporting this to the Plex support forums shortly. I've found that even with Mover tuning priority set to Very Low and disk I/O priority set to Idle, higher bitrate media still has playback issues and will often get stuck 'buffering'. I believe part of the issue is that the Plex client on most smart TVs have limited RAM to work with. The Plex for LG WebOS client is a prime example of a Plex client that fails often. And surprisingly, even the Plex for Apple TV client often buffers for high-bitrate titles. It makes less sense for the Apple TV 4K as I have a 64GB model and it has plenty of unused storage according to the list of apps under Settings. However the 3rd party Infuse Pro client on my ATV4K rarely experiences a hiccup. My HTPC using either VLC or Zoomplayer also rarely experience the buffering that seems to plague the official Plex clients. I've even played around with CPU pinning with Plex getting 3 out 4 of my hyper-threaded cores (6 threads total) and all other unRAID processes with the 1st core (2 threads). I am planning a hardware upgrade eventually to a system with more CPU cores, but in reality it still seems that the Mover process and disk I/O priority take too many resources to allow for optimal media playback. At least I have work-arounds by using Infuse or my HTPC.

Agreed. Especially for users like myself that are new to unRAID. I've learned lots since starting my trial 28 days ago, and migrated to my Pro license 2 days ago. I'm now aware that I need to check if an unRAID NVidia build exists BEFORE upgrading. A simple trap to see if the user is running the NVidia build should be possible, and then advising users to check 1st BEFORE upgrading.

For those of us running unRAID with the NVidia drivers, and I expect that's a fair number of users, perhaps update checks could verify that a build with the NVidia drivers is available before unRAID tells us that a new version is available? I just had to roll back as my Plex docker and my VM rely on the GPU passthrough and the NVidia drivers/tools. My Plex docker wouldn't even start with 6.7.2 because of the missing NVidia components. EDIT: it's actually worse than that... my install is hosed. The console at the server reports a 'segmentation fault'. I've done a shutdown after logging in at the console and have backed up my /config folder. About to use the unRAID creation tool to re-do the flash drive with a clean 6.7.1 and then restore some of my config including my Pro.key file. I noticed that network config was definitely corrupt so I'll replace that with one from last night's backup of 6.7.1. Hopefully nothing much else is wrong. EDIT 2: And now it's booting and the webgui is available, but it's started another parity check. 24 hrs to go.... EDIT 3: Had to stop the parity check as I had to reboot after re-installing the unRAID NVidia build for 6.7.1. It didn't restart the parity check after rebooting, but I suspect I'll go ahead and start a manual parity check to ensure all is OK. At least I'm back to what appears to be a functional 6.7.1 with NVidia extensions available and my Plex docker started fine. The only files I replaced from my previous flash config were network.cfg and ident.cfg.

Last night we had a small lightning show and saw numerous power bumps and one small outage. I had a pre-clear underway that was 55% through the zeroing stage. My UPS settings told the system to shutdown when the outage occurred, although it was so short that it really wasn't necessary, so I'll relax those settings later. Of course I was miffed at the thought of having to restart the pre-clear procedure. After I waited for the storm to settle down, I powered up and saw the drive sitting in UD with the preclear icon. So I clicked on it to start the process over. To my very happy surprise, it then asked me if I wanted to RESUME the preclear. Of course I did!! I've asked other questions in other threads that led to me needing to reboot my unRAID to fix the issue. I've always waited until any preclear in progress completed, sometimes meaning long delays before I could reboot. I haven't read through all the docs or this support thread, but knowing that preclears are resume-able would be something that should be a prominent mention in the features. Perhaps I missed it, but just wanted to share in case others didn't know this was possible. But one question: are there specific conditions where the preclear is resume-able? I'd assume it would only work with a clean shutdown or reboot, but perhaps not if there was a crash due to kernel panic or some other reason. Regardless, I was happy that I hadn't lost my preclear progress on the drive! Dale

I'll add my name to the list of those seeing poor response from unRAID's webgui and Docker containers whenever Mover is running. As I'm still migrating 50TB of data attached via the Unassigned Devices plugin, this is a major bottleneck. I copy about 950GB to my 1TB cache SSD, pause the copy, then manually initiate mover during which the system becomes unresponsive and Plex is unusable. If I just let the copy continue, it gets worse when the scheduled Mover run starts, which is why I pause the copy after each successive fill of the cache SSD.

@Squid I just stumbled across this gem of a tip while researching my own high CPU usage by the SHFS process.... this is a game changer for performance if your cache drive is an SSD. Made my system ultimately more useable by switching the/config folder location from /mnt/user/... to /mnt/cache/... for each of my Docker containers. I'm sure it'll work the same for any VMs I add down the road. If there's only one tip I could give to new unRAID users, this one is right at the top of the list! Thank you again! Your donation is coming shortly. This tip is especially useful for those using systems with say an older 4 core (8 threads with HT) CPU, like I am, but with the caveat that your cache drive/pool is SSD based for the best results.

It's to avoid accidentally modifying the files on those partitions, especially for the EFI partition. There's no need for it or the main OS partition to be visible to the unRAID OS, but the data partition can be used for transferring documents, pictures, etc. I intend more to use my existing Win10 SSD in bare-metal mode, but have watched the @SpaceInvaderOne video illustrating how to use it as either bare metal or a VM. Obviously it's a minor issue, but it would be a nice addition. But since I'm now aware of the User Script option, I'll use it. No worries.

I assume this means that I need auto-mount turned off for that drive in UD. And the 'User Script' is the script at the end of the line for each drive that UD supports?

Any possibility of adding auto-mount switches for individual partitions on a disk? Like @MothyTim, I'd like to use an existing SSD with a bare-metal install of Windows 10 Pro that was previously running on the same mb/cpu/ram hardware I'm now using for my unRAID build? It would be great to only mount specific partitions on that SSD rather than have UD mount them all.

I thought that the switches appeared for valid (i.e. mountable) partitions but as I said earlier, I have deleted partitions like the EFI partitions off all my UD mounted disks. I'm only using UD for data disks, but might be doing something similar with my old Win10 SSD that used the same hardware that unRAID is now using. Only my 10TB drives still have one extra partition, but since it isn't formatted at all, it's not valid and can't be mounted. If the switches for auto-mount aren't appearing when you expand the view, then perhaps I was wrong and only the 'Share' switches are visible. The current author of UD is @dlandon so he might have some suggestions for you (he'll get notified of this post because I just mentioned his username). I'm still a relative newbie to unRAID and UD, being only 16 days into my trial, but I've also learned a lot in that time, just not enough to help in this case. Hope @dlandon or others can help you.

My UD attached disks have mostly had valid but not needed partitions deleted. The exception are the 10TB drives like the one pictured above. As the partitions usually reserved for EFI are not valid, they are not mounted. That said, when you expand the disk layout by clicking on the subscript '+' symbol, each partition has it's own 'Auto-Mount' switch that can be enabled/disabled. As I have no disks with valid partitions like this left, I can't grab a screenshot to show you, but it should be in the same column as the 'Auto-Mount' switches for the disk itself, but only visible when you expand the disk view to see all partitions. Hope that helps.

If you click on the subscript '+' symbol beside the drive icon in the Unassigned Devices tab, you can unmount/mount/delete partitions. Just be careful with the delete option if you use your drive on another system that might require that partition, i.e. an EFI partition.

Thank you! I'll have to wait until the pre-clear on another drive finishes as it's in the post-read stage and has about 4 hrs to go. As Movies-A is SATA attached and my motherboard isn't configured for hot-swap, I'd have to power down to move the drive back to a Windows box for the repairs. After the disk being pre-cleared finishes, that might be moot anyhow as the new drive will be added to the UnRAID pool. Movies-A is the first disk to get migrated to the UnRAID pool, and after it's empty, it will be pre-cleared to be the next disk added. Very much appreciate the work you've done on UD and your help. I will be donating to you when my next disability cheque comes in later this month, as well as buying my Pro license for UnRAID. Only in my 5th day of using my UnRAID trial and have to say, it's been great to work with. Far easier to configure Docker and VMs than FreeNAS ever has been, at least in my experience. Thanks again! Dale

Here's the diagnostics... note that I was able to get UD to unmount after I closed the SSH shell, so that was likely keeping the drive busy. As for hibernation, this drive did come from a Win10 build but I always had hibernate disabled (powercfg -h off). And I did just note that I was using the wrong device - should have been sdm, not sdl. Here's some more details from what I just tried. Now that I have a list of what's attached to that process ID, I'm not sure how to determine what has the volume exclusively opened. These commands were performed after UD successfully unmounted the disk/volume. root@AnimNAS:/mnt/user/General# mount -t ntfs-3g -o remove_hiberfile /dev/sdm2 /mnt/user/General/usb/ Mount is denied because the NTFS volume is already exclusively opened. The volume may be already mounted, or another software may use it which could be identified for example by the help of the 'fuser' command. root@AnimNAS:/mnt/user/General# fuser -m /dev/sdm2 /dev/sdm2: 28329 root@AnimNAS:/mnt/user/General# ls /proc/28329 auxv exe@ mountinfo pagemap statm cgroup fd/ mounts personality status clear_refs fdinfo/ mountstats projid_map syscall cmdline gid_map net/ root@ task/ comm io ns/ schedstat timerslack_ns coredump_filter limits numa_maps setgroups uid_map cpuset map_files/ oom_adj smaps wchan cwd@ maps oom_score smaps_rollup environ mem oom_score_adj stat This info may also help. Note that there were about 40 - 50 of the ‘no pwd for UID 122’ messages, but I concatenated the output for here. root@AnimNAS:/mnt/user/General# lsof | grep /dev/sdm2 lsof: no pwd entry for UID 122 lsof: no pwd entry for UID 122 . . . lsof: no pwd entry for UID 122 lsof: no pwd entry for UID 122 mount.ntf 28329 root 4u BLK 8,194 0x747013ffc00 8895 /dev/sdm2 EDIT#2: One more piece of info that may help narrow down the cause/solution. I had only tried deleting dupes from the Plex interface on the Movies-A drive. That drive is an 8TB that was shucked long ago and is attached via a SATA port in UnRAID, but still mounted via UD. I have 5 other drives (10TB) that are all still in their USB enclosures and to my surprise, they are read/write and the dupes located on them can be deleted. So it's only the one NTFS drive that is direct-SATA attached that isn't allowing the deletions through Plex or via SSH. animnas-diagnostics-20190602-1744.zip

Which log? I'm a newbie to UnRAID and UD. I do know that the drive is not hibernated as I can't delete/create/write when accessing the drive via the SSH shell. I can copy files off so I know the drive isn't hibernated. It also doesn't explain why I can't unmount the drive in UD even though the auto-mount switch is turned off. Thanks for the speedy reply! Note that I even tried this with one drive that has been shucked from a USB enclosure and attached directly to a SATA port on the UnRAID system. The drive is still listed as a read-only file system. I've checked the System log under the Tools menu and nothing appears when I attempt to delete the file via the Plex web interface or via the SSH shell.

I'm having an issue with UD where NTFS USB attached drives are not mounting with delete file access. The description from the initial posts in this topic says UD mounts with read/write permissions, but that doesn't seem to be the case. I can't delete files from these drives. My main reason for this is I am slowly migrating the data from the USB drives to my UnRAID pool, with the plan to then shuck the drives and add them to the pool. In the meantime, I'm using these attached drives via UD and are mapped/mounted within the Plexinc official Plex docker container. I can read with no issues, just no write/delete access. This is an issue only when I add an upgraded copy of a title with better bitrate/resolution, i.e. adding a 4K version of a title that was previously only a 720p rip. I then want to delete the 720p rip, but Plex says it there is an error when attempting to delete the file. This leaves me with MANY duplicates until I eventually migrate all files off the NTFS drives and then remove that path from the Plex docker for the library in question. I've connected via telnet/ssh and can't create/delete/write via the shell either - response is that it's a read-only filesystem (see example below). I've also enabled the destructive mode in UD, but that doesn't seem to help. I also have successfully installed the full version of ntfs-3g but I can't mount the drives with it as UD seems to keep them auto-mounted even though I have turned off the auto-mount switch for the drives in question. Any plans to implement full write access via ntfs-3g in UD? Suggestions? Example of trying to remove/delete file from shell, but Plex also fails likely for the same reason. Permissions for the file and parent folder are the same, other than the 'd' attribute indicating directory: root@AnimNAS:/mnt/disks/Movies-A/Movies# rm The.Year.of.Living.Dangerously.1982.1080p.BluRay.mkv rm: cannot remove 'The.Year.of.Living.Dangerously.1982.1080p.BluRay.mkv': Read-only file system root@AnimNAS:/mnt/disks/Movies-A/Movies# ls -l The.Year.of.Living.Dangerously.1982.1080p.BluRay.mkv -rwxrwxrwx 1 root root 8996524675 Nov 17 2018 The.Year.of.Living.Dangerously.1982.1080p.BluRay.mkv* root@AnimNAS:/mnt/disks/Movies-A# ls -l total 256 drwxrwxrwx 1 root root 0 Apr 1 19:14 $RECYCLE.BIN/ drwxrwxrwx 1 root root 262144 May 30 04:33 Movies/ drwxrwxrwx 1 root root 0 May 11 07:11 System\ Volume\ Information/