SphericalRedundancy

Unfortunately no I didn't, I kept having other issues as well so I migrated my files off of my unraid server and stopped using it.

This still has not been fixed and its pretty ridiculous depending on the type of rules you want to use. Using something as simple as the rule below means you can only have 8 hosts per share without messing in the exports file. 192.168.10.5(sec=sys,rw,sync)

I currently have 8 NFS shares that are all working as expected configured as a private NFS share but I noticed today when I attempted to add a 9th NFS share that although the entry gets added to the /etc/exports file it does not actually export the new share as shown by showmount or exportfs -v. I noticed that when I run exportfs -ra to re-initilize the NFS service and have it export shares configured in /etc/exports it shows an error message about incorrect syntax for a bad option list. This points to line 9 in the /etc/exports file but line 9 is a completely different share that is currently working normally and exported successfully. If I remove line 9 by disabling that share in the Unraid GUI, the syntax error just moves up one line but I don't see any issues with the content of /etc/exports and I wouldn't expect any errors considering I haven't manually edited the file. All entries in /etc/exports were added by Unraid itself. I've attached some other images below for reference, the NFS share that is not working as expected is /mnt/user/tv. Unraid share settings in GUI: Content of /etc/exports: # See exports(5) for a description. # This file contains a list of all directories exported to other computers. # It is used by rpc.nfsd and rpc.mountd. "/mnt/user/backups" -async,no_subtree_check,fsid=102 192.168.1.10(sec=sys,rw,sync) "/mnt/user/comics" -async,no_subtree_check,fsid=108 192.168.1.38(sec=sys,ro,sync) 192.168.1.33(sec=sys,ro,sync) 192.168.1.17(sec=sys,rw,sync) "/mnt/user/downloads" -async,no_subtree_check,fsid=100 192.168.1.51(sec=sys,rw,sync) 192.168.1.52(sec=sys,rw,sync) 192.168.1.44(sec=sys,rw,sync) 192.168.1.27(sec=sys,rw,sync) 192.168.1.53(sec=sys,rw,sync) "/mnt/user/ebooks" -async,no_subtree_check,fsid=109 192.168.1.38(sec=sys,ro,sync) "/mnt/user/instructional" -async,no_subtree_check,fsid=110 192.168.1.38(sec=sys,ro,sync) "/mnt/user/movies" -async,no_subtree_check,fsid=107 192.168.1.47(sec=sys,ro,sync) "/mnt/user/other" -async,no_subtree_check,fsid=112 192.168.1.33(sec=sys,ro,sync) "/mnt/user/proxmox-isos" -async,no_subtree_check,fsid=105 192.168.1.14(sec=sys,rw,sync),192.168.1.15(sec=sys,rw,sync) "/mnt/user/tv" -async,no_subtree_check,fsid=106 192.168.1.47(sec=sys,ro,sync) Output of exportfs -v Any help with be very much appreciated as I don't understand what is happening. Thank you,

Is there a way to update to a version that's above 6.5.3 but isn't 6.6.5? My server has been running smoothly for months and I avoided updating because I wanted to wait until 6.6.X was cleaned up of any of the bigger bugs but when I updated to 6.6.5 last week my server has crashed everyday since, downgrading to 6.5.3 and it no longer happens. I'd like to update to something other than 6.6.5 so that maybe I can narrow down which update is affecting me.

Yea it's on lan, was using chrome, same thing for firefox though.

So I just did this and its all working great except that after I installed the red hat qxl display controller driver, the black border around my mouse cursor was removed. So when I mouse over the file explorer, or anything that's got a white background, I can't see my mouse at all. Anyone got any ideas?

Is it normally so slow? It takes several seconds after clicking or typing for anything to happen.

I guess they could also implement logic to only move to cache if moving to a different drive and skip cache if moving to the same disk just a different folder. For now I guess I'll have to move share B to an unassigned device since I don't actually care about it being protected. I assume since that is outside of the array that I'd then be able to transfer to share A and it'd use the cache drive?

So I've got 8 data drives, a parity drive, and a cache drive. So lets say I have two shares, share A is set as yes to use the cache drive while share B is set to not use it at all. I will sometimes need to transfer large (100 GB or more) folders from share B to the share A. Whenever I do this the transfer speed is very slow ranging from 5MB/s to 10MB/s and as far as I can tell this is because share B is not only writing to share A but also the parity. Why doesn't share B transfer to the cache drive first since share A is set to use it?

Ah, gotcha. Would 5 minutes be alright?

Why is the drive temperature shown as an asterisk here? Happens to the bottom two drives sometimes.

Thanks for that, that seems to work well!

Gotcha, so yeah I did have it set incorrectly. Is there a way to have unraid move the files around again so they follow the new split level rules?

The folders I copied were all tv shows for a single share and the share is set as follows. So that would be an example of how I have the tv share laid out, tv (share name) > type > bunch of different shows per type > season folders per show I have it set to split at level 2 which I think would only keep the season folders together? although based on your previous sentence and calling the share name itself the top level maybe it should be set to split at level 3?

So I must be doing something wrong. Why is unRAID doing this? I moved a bunch of folders onto my cache drive totally about 750GB (my cache is 1TB) and before moving it disk 1 had about 900GB available and it seems like unRAID decided to move it all to one drive and I have no idea why. I'm pretty sure I have my split level set right on my shares but I don't know at this point.