DiscoverIt

Thanks. Will keep this FR open as I prefer a built in scenario adding these two little options instead of relying on two plugins.

This does not allow disabling or setting custom cron for the mover? Say i wanted to run every 10th day, or bi-monthly, or not at all.

At present the mover cannot be programmed for a custom frequency or the ability to disable. Would like to propose the addition of Disabled & Custom entries with custom displaying a text box for a manual crontab entry.

Definitely one of those plugins I didn't know I needed until now. thanks!

what we’re doing now is creating multiple single disk XFS pools and utilizing snapraid to create a parity drive for said pools. It’s not ideal but allows for a round about unraid array for cold storage data.

So not a quick find and replace ey? Multiple arrays has topped the yearly wish list for half a decade plus and I’d have to assume that multiple arrays will be a massive lift. For now I’ve resorted to snapraid but would be nice to roll these drives into an array; either as a multiple or expanded array.

With multi-array still out for discussion, can LT simply bump the arbitrary limit of 28/2 up to say 43/2 to allow full usage of a 45 bay JBOD in a single pool using the Unraid array model?

The new way keys are handled via Connect?

IIRC a user can only migrate their key once yearly via the web portal. Was curious if the change in activation backend would allow additional changes per year.

Bummer, just adds even downtime. Is there any basis for continuing the 1x yearly migration when its handled via the new web portal now?

To further the research it appears you cannot use a fresh USB, apply a trial and then back apply the previous config either? Is it simply checking super.dat / config modification date or a field within?

Were the trial key restrictions and limitations recently modified? I run a mirrored UnRaid boot USB in an attempt for closer to near instant fail-over in the event of a USB drive loss. It seems however you can no longer have an existing config present on the USB to request a trial key? Is the key verification performing some sort of date or timestamp verification now as you can request a trial on a fresh USB but cannot if the contents of config predate the request date? Reason for the trial is to prevent burning my 1x yearly automated key migration on a spare USB key.

It’s always soon. I have a growing need for more drives and not incredibly keen on making 30+ individual xfs drive pools protected by SnapRaid. I’ll keep poking for another hacky option that will yield better results. Thanks!

What will never work?

The fix is to not use an old nfs version. v3 was prone to this but v4 remedies it.

Seems not terribly straight forward with many legacy hard coded sections capping at the 30 disks total for an unraid array. Bummer

What controls /var/local/emhttp/var.ini? It seems upon modification changes are immediately reverted. Through some poking and proding it seems that MAX_CACHESZ is going from 60 drives in 6.12 to 120 in 7.0. Out of curiosity and boredom I'm trying to see if the same applies for MAX_ARRAZYSZ as I'd really like to toy around with 45 or 60 wide unraid array. In testing it seems the var.ini file is not persistent as any changes are immediately flushed. Was ideally thinking of throwing a sed into /boot/config/go /boot/config/go #!/bin/bash # Brute force array change sed -i 's/MAX_ARRAYSZ="30"/MAX_ARRAYSZ="60"/' /var/local/emhttp/var.ini # Start the Management Utility /usr/local/sbin/emhttp & #resize memory allocation mount -o remount,size=8G /dev/shm mount -o remount,size=120G / #load custom nfs exports cp /boot/config/custom.exports /etc/exports.d/custom.exports

I'm curious on your stance with you being frankly a key pillar in this eco system. Why are you against exclusive access shares if a share such as appdata resides solely on say cache? The setting (which imo should be default if the share meets certain settings) makes an opaque layer of the system transparent with nearly no downside to the end user. Imo the only rationale I can find is that you cannot create an NFS export of an exclusive share without some side hackery.

Exclusive share is the way to go. While its not enabled by default it can be enabled if a user has a share which solely resides on a non-unraid pool. This could be addressed with a notation in the description or tool tip for the required containers. IIRC I've seen others (maybe a SQL template?) indicate exclusive shares should be used for performance and reliability purposes. I cannot speak for segfaults in a default /mnt/user configuration and while a stretch maybe there is some need in a feature request to have a hidden/advanced field for "Requires Exclusive Access Share", dunno. My main beef with /mnt/cache as default is it relies on an educated user when the UnRaid user pool is often on the other end of linux/nas/server knowledge spectrum. Many instances have occurred where the user specifies /mnt/cache because SpaceInvader once did a video on it years ago but then fail to correlate that a running mover breaks their setup. The data isn't gone but since the service is only looking in /mnt/cache it fails to see the majority of share data (<v7) is now residing in /mnt/user0.

Understood but why would it be correct when up until recently the usage of exclusive shares was not a thing? If the user specifies in the global setting level the usage of /mnt/user/appdata I wouldn't expect it to resolve instead to /mnt/cache/appdata when /mnt/user/appdata is still a valid location. With exclusive share off for appdata the resolving occurs as expected and uses /mnt/user/appdata. I could see it resolving differently if the global setting was /mnt/zfs_cache/appdata and the user really has /mnt/cache/appdata so its instead resolved to /mnt/user/appdata.

The issue is that CA/dockerMan is not respecting the host default. In an exclusive share scenario the symlink target overwrites the template entry. As an aside. Any developer doing a commit to make the template default to /mnt/cache or similar should be flagged for blacklisting. I potentially put this into the wrong channel as it sounds more like a dockerman issue and not CA?

It seems when a share is marked as exclusive and a new template is installed the default pathing is incorrect due to CA pulling the symlink target and not the symlink link_name. eg; exclusive access for appdata residing on a pool called cache; /mnt/cache/appdata vs the proper /mnt/user/appdata

vibr0 is used by libvirt to create NAT'd VM's on UnRaid. One drawback to this approach is that it ties up port 53 which is required by containers such as PiHole and AdGuard. I'd like to propose a toggle within VM Settings to disable vibr0 and to free up the key system port. It does not seem vibr0 is commonly used so I would further suggest disabling as default. In the meantime it seems brctl delbr virbr0 could suffice?