limetech

As I noted several times, the issue is interaction within the controller -- NOT the Windows connection. You get this behavior even if you're accessing the array from multiple clients (each with their own SMB connection) ... and independent of what the client is [Windows, Linux, Apple]. If it's too complex to retain, so be it ... but it DOES resolve an issue that can be a bit of a nuisance (but not, in the great scheme of things, a big deal). One very simple way to bypass the issue entirely is to simply hit the "Spin Up" button whenever you're going to have multiple folks using the server ... and perhaps set the spin-down timer to a moderately long time (2-3 hours). Actually it was both, which is why some of the spinup issues in the past were so baffling - any time there are two or more issues happening at the same time it becomes very difficult to figure out what's going on. Specifically: a) there was an issue with IDE style controllers, which were really 'channel' interfaces, that only allowed command/response to a single device at a time. And this includes early SATA controllers which were bolted on to IDE/PATA controller designs. b) single-connection nature of windows. Not sure if this is still the case, especially now with SMB3 protocol.

unRAID doesn't cause the stall but the bandage fix on the unRAID side is to use spinup groups. It's a Windows problem. Windows basically creates one connection to the server so when a second program tries to access a spun-down disk the connection hangs until it gets a response. Right!! The reason I commissioned the poll is this. The code that implements spinup groups is somewhat complex. This is because in order to implement, the test for whether "other" disks of group should be spun-up as a result of I/O to any particular disk is done right in the driver I/O path. Because of this we cannot simply execute something like 'hdparm' to interrogate the drive because it would occur on every I/O making it run really sloooooooooowwwww. Instead we must maintain spinning state in the driver, meaning a simple integer flag that is tested. But in order to do this, the driver has to maintain this flag. Anyway, longtime unRaid users will recall that spinning status has been "problematic" over the years, and it's easy to break - latest occuring in 6.1-rc2. I'm thinking the time to eliminate all this code is going to be with the introduction of P+Q support, and all my code documentation that refers to spinup groups talks about reason being to support master/slave on IDE channel. (What Gary talks about here: http://lime-technology.com/forum/index.php?topic=41877.msg398674#msg398674). But in back of my mind I seemed to recall there was another case that was solved by spinup groups and that is the Windows single SMB connection case. So looks like I need to keep the code in place.

When the share is empty there is a Delete checkbox next to the 'Apply' button on the share's edit page. When you check this box the Apply button label changes to Delete. To empty the share, navigate to it under Windows Network (or OS X Finder) and delete all the files/directories. There is a bug in 6.0.0/6.0.1 where certain files may not show up via network access. These are files which, on the server side, start with a dot (this is how files are "hidden" in *nix O.S.'s). Normally you never have these kinds of files, but depending on which Apps (ie, docker containers) might access your shares it's possible some of this junk is left behind and the share will not appear "empty".

Huh, not sure how that might have happened. If you are wanting to totally empty that share, then yes that command will delete everything under that directory (share) name.

Everything looks good in there. Probably you have some left over 'hidden' files in that share. The easy way to deal with that is to wait until 6.1 'stable' is released, where we display those so-called 'dot' files in network directory listing. That makes it possible to delete those files via Windows. The other way to delete those involves using the console/telnet command line to type the command to delete them. In this case, after logging in, first examine what's in the share - not sure which share you are tying to delete but let's say it's "data": ls -la /mnt/user/data If that command shows any files that start with '.' (dot) that's the problem. To remove all those files: rm -r /mnt/user/data/* You should then be able to delete the share via Share Edit page. Sorry for the inconvenience.

Now please go to Tools menu and click on Diagonstics and then attach that file to your next reply.

First of all 6.0-rc5 is no longer supported. Please upgrade to latest stable release.

Perhaps, LimeTech should get the Linux equivalent of make_bootable, include it in the plugin and run it as a part of the upgrade plugin. Hey that's a good idea I'll look into it.

It's in both places.

With release of 6.0.1 the plugin that handles updating v6 also can upgrade v5 to v6. Read this first: * Make a backup of your USB Flash device. * Take a screenshot of your webGui Main page. This will make it easier to restore your disk assignments if necessary (shouldn't be). * Do not try to use this plugin if you are coming from a version of unRAID prior to v5.0-beta6, including all v4 releases. Please use the Upgrading to UnRAID v6 guide as a 'clean' install, and do not attempt to restore your configuration files. You will need to assign all of your drives again in v6. * If you have never run the New Permissions tool, or are upgrading from a version prior to v5.0-rc9, then you MUST run the New Permissions tool, even if you have run it before. It's on the v6 Tools page. * Whether you use this plugin or not, it is recommended to read the Upgrading to UnRAID v6 guide. There are two methods which can be used to upgrade using this plugin: Method 1 - using command line Use console or telnet session to log into your unRAID-5 server. Use 'wget' command to fetch the unRAIDServer.plg file: wget --no-check-certificate https://raw.githubusercontent.com/limetech/unRAIDServer/master/unRAIDServer.plg Then perform the upgrade by typing this command: installplg unRAIDServer.plg When upgrade has completed, reboot your server. Method 2 - using reboot sequence Download the unRAIDServer.plg file to your PC from this link (windows: right-click, save-as): https://raw.githubusercontent.com/limetech/unRAIDServer/master/unRAIDServer.plg Copy the file to the 'config/plugins' directory on your 'flash' share. Reboot your server TWICE. That is, the first time your server is rebooted, it still boots into unRAID-5 but during the boot process it will download and install the unRAID-6 release. Reboot a second time to actually boot into unRAID-6. What the upgrade does: - Checks that your CPU is 64-bit capable - Downloads the 32-bit version of ‘infozip’ package from slackware.cs.utah.edu into /boot/extra directory. This is needed for the ‘unzip’ command. - Downloads the ‘latest’ unRaid-6 release zip file and md5 file from the LimeTech Amazon-S3 account. - Verifies there is enough free space on the flash. There needs to be around 150MB free space. - Unzips release and copies release files to temp directory on flash. - Preserves the current unRaid-5 release files to a directory on the flash called ./unRAID5 - extra/ - packages/ - plugins/ - config/plugins/ - config/plugins/go - Copies the release files from temp directory to root of flash device. - Copies a fresh ‘go’ file to the config directory. - If your key file is in root of the USB flash, it’s copied to config directory. When the server is booted into unRaid-6 it's a fully 'stock' install, but with your unRaid-specific config files intact. Meaning all your disks assignments, users, etc. should still be present. [glow=red,2,300]ALL PLUGINS AND EXTRA PACKAGES WILL NOT BE UPDATED[/glow] To add missing functionality provided by unRAID-5 plugins, please look for equivalent unRAID-6 Docker containers. If you decide to revert back to unRAID-5 this can be accomplished using this command: plugin remove unRAIDServer.plg

Added that driver for you to unRaid kernel for 6.0.1 release.

I'm assuming for 'Rule' on NFS share settings for Private share you set to "192.168.2.2(rw)" right? If I look at /etc/exports it appears correct, yet output ouf 'exportfs -v' does indeed show (ro). Never noticed this before - is there something wrong inside /etc/exports (asking you guys who might know this before I go research what's happening)?

It should work to Stop array, then click on the device in question. On that page, select 'XFS' as the file system type, click Apply. Now back to Main, Start array and that disk should come up 'unmountable' and there should be a Format button - if all appears as I describe, click it!

I agree with you in that context. I'm not sure this needs to be a persistant warning when it comes to Cache-only shares, because ostensbily you are using your cache only share for plugins/docker apps and it's only housing data you are ok with losing. I agree with Gary that this shouldn't exactly be a Green Cricle either, as it's not the same condition. The fact a share is cache-only does not necessarily mean it's not on 'protected' storage. If you have 2-or-more-device cache pool, then your cache-only share is protected and gets a green ball.

It means "WARNING: if the wrong device Fails you may lose data." Thought of in that context, the symbol is appropriate.

Why? Single click on the share tells you how it's configured. It's very easy to make indicators useless by having too many states. The idea is that one should be able to glance at the page from across the room and see all Green - if some other color shows up, now you have to investigate further.

"Disabled" (red X) means that the device has failed and is no longer accessed by unRaid in any way. Whether the device is physically present or not, with the exception that when array is stopped the device may be queried by linux to find out it's ID information. The reason we don't access it is because depending on nature of failure it can bring everything down to a crawl. "Invalid" (yellow triangle) means that a device is present but its data contents are "invalid" - meaning if you were to mount the device on its own, not all the data would be there. A device in the Invalid state is being emulated by unRaid for reads but writes go through. Normally you only see this status while a device is being rebuilt (reconstructed), but if you Cancel the rebuild before it finishes the device will retain this Invalid status. "emulated" means: for a disabled device: all reads are satisfied using reconstruct-read; all writes update the parity disk. for an invalid device: all reads are satisfied using reconstruct-read; all writes go through

There is no specific 'color' status for that mode, but that's a good reason to add one.

There's been several discussions in various threads and on github about what to use for the (affectionately named) "colored balls" that represent various states of the server, devices and user shares. What colors should be used? What shapes should be used? What should the rollover say? What operations can be triggered by clicking one of these balls? First I will document what the code generates, and then some thoughts, and then let's use this thread to come to a consensus on what should be implemented for unRaid-6 'stable' release. Here's what's generated: Array States 'mdColor' 'mdState' green STARTED array started, there is no DISK_INVALID disk yellow STARTED array started, DISK_INVALID disk present, reconstruct may or may not be in progress red STOPPED array stopped Array Disk States These states can exist whether array is started or stopped: 'color' 'status' grey-off DISK_NP no disk present, no disk configured green-on* DISK_OK disk present and data is valid yellow-on* DISK_INVALID disk present but not all data valid, reads emulated, writes go through, reconstruct may or may not be active red-on* DISK_DSBL disabled (emulated), old disk still present, no i/o at all to the device red-off DISK_NP_DSBL disabled (emulated), no disk present These states can exist only when array is stopped: 'color' 'status' blue-on* DISK_DSBL_NEW disabled, new disk present upon Start transitions to DISK_INVALID (see Notes below) red-off DISK_NP_MISSING disk is enabled, but not present upon Start transitions to DISK_NP_DSBL (if only one disk in this state) red-on* DISK_WRONG disk present, but not correct disk upon Start transitions to DISK_INVALID (if only one disk in this state), or transitions to DISK_OK (if multiple disks in this state) blue-on* DISK_NEW new disk upon Start transitions to DISK_OK (caution: assumes partition 1 is completely cleared) Notes: 1. Colors marked with * can either be -on or -blink depending on device standby state (-blink if in standby). Note that when array is Stopped no devices will be in standby state, though user may be able to put device in standby. 2. At most one disk can be in DISK_INVALID, DISK_DSBL, DISK_NP_DSBL, DISK_DSBL_NEW state. 3. If more than one disk in state DISK_NP_MISSING, array can't start. 4. If more then one disk is in state DISK_WRONG we assume user just rearranged slots, we don't actually check if it's the exact same set of devices (this should probably be fixed). 5. Upon array Start, if there is a disk in DISK_INVALID state, we kick off a reconstruct. Cache Disk States 'color' 'status' grey-off DISK_NP no disk present, but not first device of multi-disk pool grey-off DISK_OK_NP no disk present and this is first device of multi-device pool green-on* DISK_OK disk present blue-on* DISK_NEW new disk upon Start transitions to DISK_OK Notes: 1. Colors marked with * can either be -on or -blink depending on device standby state (-blink if in standby). Note that when array is Stopped no devices will be in standby state, though user may be able to put device in standby. 2. The special DISK_OK_NP is necessary because webGui reports all pool info through first device of multi-device pool, which is permittted to have no device installed. 3. Upon array Start, if this is a newly created multi-device pool, or count of pool devices changes, a background "btrfs balance" operation is initiated, which can fail if pool has shrunk by too many devices. User Share States 'color' green share directory exists on array disk(s) only yellow share directory exists on array disk(s) and cache disk/pool red share directory exists on cache disk/pool only The idea is that 'color' would be used to generate the name of an icon image file to display for the corresponding state. For example, orignally "green-on.png" was a green solid ball and "green-blink.png" was a green blinking ball. Similarly, "red-on.png" was a bright solid red ball and "red-off.png" was a dim solid red ball. You can see in general, "-off" means device is not installed in that slot; and "-on" means device is present, not in standby; and "-blink" means device is present and in standby mode (ie, spun down). As unRaid webGui progressed, people decided they didn't like blinking, and then decided they didn't like just colors. So efforts have been made to introduce various shapes, symbols, etc. to translate those "color" specifications. Alright, here's your chance to chime in! Got some ideas? Let's see your color => image file translations! If necessary I'm willing to add more states if necessary too. (For instance for mdColor could generate 'yellow-off' for no reconstruct possible, 'yellow-on' for reconstruct possible but not in progress, and 'yellow-blink' for reconstruct in process. Reason I didn't do this was, well, didn't need to, but maybe this would be handy if we want to display a different icon for these states.)

What sort of dependencies exist at "install time" for a plugin? I really would like to avoid having to introduce plugin install ordering mechanisms. I want to eliminate the 'system' plugin concept, and it's only left in unRaid-6 as a way (if necessary) to update the plugin manager itself. For example, a new 'plugin' script could be installed using system plugin so that all subsequent user plugins get installed with this new script, but I've never had to do this. I agree the 'Stale Plugins' idea is not very useful and is a source of confusion. Probably this will get eliminated from the webGui but the 'plugin' script will still maintain the 'plugins-stale' directory on the flash.

peter_sm- yes, very nice! One plg file to rule them all! Now put your icons inline using the "base64" attribute. For example, for Device_status.png... Change: <FILE Name="/boot/config/plugins/openvpnserver/device_status.png"> <URL>--no-check-certificate http://lime-technology.com/wiki/images/9/97/Device_status.png</URL> </FILE> To: <FILE Name="/usr/local/emhttp/plugins/openvpnserver/device_status.png" Type="base64"> <INLINE> iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABHNCSVQICAgIfAhkiAAAAAlwSFlz AAAN1wAADdcBQiibeAAAABl0RVh0U29mdHdhcmUAd3d3Lmlua3NjYXBlLm9yZ5vuPBoAAAFJSURB VDiNtZI9awJBEIafVctUSv6KvUUCEpPiDhsFsT2CVcSt5OqzlWBvKzb5QDCCvX8lYL2zsm4alTtR MYRM987OPLzzssp7z1+qcKo5m81u8/n8s1KqDuC9nzjnXqvV6vdVAOecds69pFoxcAN0TwKm0+kS WG+326Rer69EpA2glLrbOfgC2kB3MpmUc7mcBophGFZyACKiRYTNZqN3uiQiBEGwCIJgISKISAnA WquNMYiIPjhoNBorINzbMsZkbKZ1s9kM028FgNFo9AE8AJ9RFNVEJANI6+PZAkAURbVzC8f6eLYA MBgMyt57DRS11pVLgCRJlsBaKZX0er3VIURrLcaYfYiZpbQ2xmhrbTbEfr+fCeaSgziOM4Grf/nK nU7nJHU4HKqrACIy997fp3tKqfmp2bMntFqtN+BxJ9/H4/HTrwDX1g/Ee8aNyc3z/wAAAABJRU5E rkJggg== </INLINE> </FILE> You can use the 'base64' command to convert a binary to base64. For example, what I did was download your Device_status.png file to my current directory and then typed: base64 Device_status.png This will spew out the block you see above. Next I used mouse to select it and paste into this post. There are also online base64 encoders that will do the job as well. Notice also, the icon is created directly in /usr/local/emhttp/plugins/openvpnserver/ - no need to save it on the flash separately (because it will always be regenerated when the plugin gets installed at boot-time). Once this is done, no more dependency on the unRaid wiki. Finally, I don't think it matters too much, but this is the mirror we use to fetch slack packages: http://slackware.cs.utah.edu/pub/slackware/slackware64-current/slackware64/

Yeah, my mistake, fixed in beta9.

It's leftover from a previous install of older openvpnserver plugin.

A couple of suggestions: Based on a post by Tom: /usr/local/emhttp/plugins/ssh/Ssh.page # page file for webGui menu system /usr/local/emhttp/plugins/ssh/Ssh.php # webGui page code It seems that the page file and the php have to both be exactly the same name. I think his idea here is to insure the icons are in alphabetic order in the settings page. Also the versioning standard seems to be year.month.day for plugins. Right, if you have a php file then it has to be same name as page file only with php extension. The page file itself, beyond the '---' separator is interpreted as "markdown", but with markdown, anything within <> tags is passed straight through (we use markdown extra). Example, suppose you have "HelloWorld.page" like this: Menu=Tasks Title="Hello Word" --- **Hello world!** <?php echo "Here is some php.<br>" ?> So you don't really need separate php files. You could do the same thing using two files like this: HelloWorld.page: Menu=Tasks Title="Hello Word" --- **Hello world!** HelloWorld.php: <?php echo "Here is some php.<br>" ?> As for versioning - yes standardizing on "YYYY.MM.DD-RR" (-RR is optional "revision"). But anything will work as long as a php strcmp() function comparing the versions of your plugin works correctly to tell newer version from older version.

It works for me. There is this in the plugin install window: /boot/config/plugins/openvpnclient/openvpnclient.cfg: line 7: a: command not found But I see the icons and it seems to be installed correctly. I'm running (unreleased beta9) and did make some changes plugin code - I'll have to boot a beta8 server to verify again.