JonathanM

I'm on 6.2 and there doesn't appear to be a way to 'Start' the array with the swapped assignments. I'm getting... The 'Start' is grayed out and nothing to tick to continue. I'm presuming, it's not necessary to swap assignments, if I'm keeping track of the drives through the migration. WAG, but you can't swap assignments if you have both parity disks enabled and valid. Single parity - switching slots allowed, Dual parity - slots not movable without recalculating Q parity. It's not necessary to swap things around as long as you don't use disk specific locations, and even then it's fine as long as you change the assignments to track the new disk number. Thanks, but I'm only using single Parity. Also don't have User Shares. Unlike v6.1, v6.2 doesn't allow disk swapping even when using single parity, Tom already posted that this will be fixed on a future release. Must have missed that discussion. So, for now if you want to move disk assignments, you will have to set a new config and carefully assign the drives where you want them. Just be ABSOLUTELY positive which drive is your parity drive. You can check the box to indicate parity is already valid, but I would do a parity check afterwards anyway. Unless you have a pressing need to keep each migration's disk assignments correct, I'd just wait til you are all done, then reassign all disks at once.

I'm on 6.2 and there doesn't appear to be a way to 'Start' the array with the swapped assignments. I'm getting... The 'Start' is grayed out and nothing to tick to continue. I'm presuming, it's not necessary to swap assignments, if I'm keeping track of the drives through the migration. WAG, but you can't swap assignments if you have both parity disks enabled and valid. Single parity - switching slots allowed, Dual parity - slots not movable without recalculating Q parity. It's not necessary to swap things around as long as you don't use disk specific locations, and even then it's fine as long as you change the assignments to track the new disk number.

If you can't wait, the krusader docker supports it already.

Now that you've almost got Android and iOS worked out, the next logical step is a desktop widget for windows/linux/macos. Since you have GUI user permissions sorted, a desktop app would fill a need for limited user control of the server from various family members desktops or laptops. Maybe a chrome app?

Temporarily change your boot image for that VM to a bootable gparted iso, or any of the live linux cd's that include gparted.

The flash drive is FAT32, which does not support permissions. No workaround.

As a test, disable the vpn in the docker settings and see if you can access the webgui. If you can, then the issue is in your VPN settings, so you can concentrate on that. If you can't access the webgui with the VPN disabled, then you have other issues that need to be addressed before you can work on getting the VPN portion working.

None that I know of. Maybe one, if the drive is detected to have failed, unRAID may unmount it. Perhaps I should somehow cause the drive to appear to have failed... A failed drive's content still appears at the /mnt/diskX location, but the link to the physical drive is gone. We need the physical drive to still be linked to the md device so the script accomplishes what is needed. I still think unraid shouldn't automatically create /mnt/diskX locations that don't correspond to what's on the drive. I would expect the GUI line to show unmountable, reflecting what's actually happening. I guess it all boils down to this process being seen as unnecessary from Limetech's point of view, since we've been talking about it and doing it for years, without input from Tom. So, we continue to hit the nail with the handle and hope we don't break it.

I noticed that every time I used the script to clear a 250GB drive, some time after it unmounted it (didn't watch so don't know how soon), the Main screen showed a valid disk mounted there but with a little over 2GB size drive there, and a little of it used, don't remember the numbers. I just assumed normal wonkiness when I confused it by unmounting it, and never investigated further. What you found sounds exactly the same. I never noticed any issues. When the clearing finished, I stopped the array and went to New Config, which essentially reset everything. A parity check found nothing wrong. I saw the same lines in my syslog. I think this is something that Limetech needs to look into. Not your script, but the auto creation of a disk folder not linked to the underlying md system. I can imagine some very strange things happening if a disk is unmounted and things are written to the phantom drive. I didn't test to see if the newly minted disk1 would participate in the user share system, but I assume it could. Are there any circumstances that could cause the disk to unmount without a direct call from a user intiated command?

I'm playing with Rob's clear drive script, and noticed something very strange. After his script unmounts the drive, emhttp immediately recreates the /mnt/disk1 by chmod it, I guess in RAM. I don't know if it's something wonky with my system, or a bug in unraid, or what. Sep 19 19:10:30 Testunraid emhttp: cmd: /usr/local/emhttp/plugins/user.scripts/backgroundScript.sh /tmp/user.scripts/tmpScripts/clear an array drive/script Sep 19 19:10:44 Testunraid emhttp: cmd: /usr/local/emhttp/plugins/user.scripts/showLog.php clear an array drive Sep 19 19:11:30 Testunraid clear_array_drive: Clear an unRAID array data drive v1.4 Sep 19 19:11:30 Testunraid clear_array_drive: Unmounting Disk 1 (command: umount /mnt/disk1 ) ... Sep 19 19:11:30 Testunraid clear_array_drive: Clearing Disk 1 (command: dd bs=1M if=/dev/zero of=/dev/md1 status=progress ) ... Sep 19 19:12:01 Testunraid emhttp: shcmd (807): chmod 0777 '/mnt/disk1' Sep 19 19:12:01 Testunraid emhttp: shcmd (808): chown 'nobody':'users' '/mnt/disk1' /dev/md1 is clearly no longer mounted at /mnt/disk1 root@Testunraid:~# mount proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) tmpfs on /var/log type tmpfs (rw,size=128m,mode=0755) /dev/sda1 on /boot type vfat (rw,noatime,nodiratime,umask=0,shortname=mixed) /mnt on /mnt type none (rw,bind) /dev/md2 on /mnt/disk2 type xfs (rw,noatime,nodiratime) /dev/sdf1 on /mnt/cache type xfs (rw,noatime,nodiratime) shfs on /mnt/user0 type fuse.shfs (rw,nosuid,nodev,noatime,allow_other) shfs on /mnt/user type fuse.shfs (rw,nosuid,nodev,noatime,allow_other) /mnt/cache/system/docker.img on /var/lib/docker type btrfs (rw) /mnt/cache/system/libvirt/libvirt.img on /etc/libvirt type btrfs (rw) root@Testunraid:~# I have disk1 globally excluded from shares.

My recollection is the same. I used mariadb for the database, and it worked, but I didn't like having to import and using twice the storage space. I'm still looking for a photo solution.

Can't help with your problem, but you need to log in to your VPN provider and CHANGE YOUR PASSWORD, ASAP.

Drunk glasses. https://www.lifeloc.com/goggles.aspx Probably great fun to wear after having actually had a few too many. Previous post no longer needed, so removed.

Oh, also I believe the VNC cursor issue is client related. The noVNC web client can be a pain, sometimes toggling between full screen and back to windowed can help sync the cursor, if that doesn't work for you I suggest connecting with a real VNC viewer, Remmina works well if you are linux based, I saw a couple pages that seem to show how to use it in OSX. Trying to work with a cursor that is out of sync reminds me of trying to walk with the drunk simulator prism glasses that some driver's education classes use. Entertaining for about 2 seconds, and extremely irritating thereafter.

It would be easier to just use Binhex's DelugeVPN, it does exactly what you want, all in one container.

But modular cables introduce another slip fit mechanical connection at the point they plug in to the PSU, effectively negating the advantage of not using splitters. Permanent solder joints are a much better idea reliability wise. Agree on the permanent solder joints, but I have yet to see a modular cable connector that didn't make a better connection than a molex splitter. Stop using poorly made molex splitters? Seriously, there sometimes is a huge quality difference between branded and generic stuff when it comes to connectors. Different alloys, tighter tolerances, better coatings, all the qualities that matter when you have a slip fit spring connection. Visually it may not be much different, but it sure makes a difference after they've been in service a few years.

But modular cables introduce another slip fit mechanical connection at the point they plug in to the PSU, effectively negating the advantage of not using splitters. Permanent solder joints are a much better idea reliability wise.

AFAIK an established pool has NEVER been automatically reverted on reboot, but if you make changes to the pool you will have to manually adjust the balance command to reflect what you want, as the balance command defaults back to RAID-1. That may be what you are referring to, and that hasn't changed.

Can you post a screenshot after you filled in the paths to your config and data?

Quick suggestion. The top right button is currently called "Update Applications". Instead of being ambiguous over what is actually being updated, why not call it "Update App List" or "Refresh App List" or something like that? Since your program does app backup and such, it's not a stretch to imagine the current button would literally update your installed applications.

What would the cost / benefit ratio of either adding a variable or setting up a second container so we could choose? My install is currently mostly working so it would be nice to be able to switch back easily if something in the master branch build is badly broken.

Your parity disk is just a bunch of bits that have absolutely no meaning without the other disks in your array. However... it is possible that chunks of that data contain meaning. Consider the scenario where all disks are precleared, and only 1 drive has data. The parity drive would contain the mostly intact contents of that single drive, and running data recovery software would yield some readable files. Any region of the parity drive where all other data drive content except for 1 is zeroed would mirror that specific data. No format structure would be available, so raw recovery with binary analysis would be required to find any information. tl;dr - clearing the parity drive before letting it leave your control is a good idea if there is sensitive data on the server. If you are storing data that must not be released under any circumstance, I do not recommend RMA'ing dead drives. Destroy them and eat the loss.

That feature is already available, has been there since day one. To turn it on, simply unplug your ethernet cable. Ha! Yes, that is the obvious solution, but not all of us have easily accessible infrastructure. I typically down the server before messing with any of the wiring, just because I don't want to be moving things around with the server up, and it's a pain to get to otherwise. With IPMI, I have a local console anywhere, so downing just the network interface programmaticly is a much easier option. If it's not in the cards, I understand. Just wanted to offer an option to make testing more consistent.

In this same vein, it may be productive to offer the option to take down the ethernet interface for the duration of the test. That way if it suits the user, they could remove the possibility of external influence during testing. Trick would be to only allow it if there was local console access to get back from a bad state. Can you detect in your script if it was called from a local console?

You can do a force update to get it to the new .23 How do you force an update? Advanced View