Joe L.

Exactly. It was originally conceived as a way to explore improvements that could be made to the stock GIU. It is not designed to replace the stock GUI. It is a supplement to any other GUI. It still provides more than even the latest dynamix. It was designed to be easily extensible. In fact, the unRAID plugin system is loosly based on what I originally designed for unMENU... it just uses .xml for its package manager and unMENU uses straight text. See this thread for the original history: http://lime-technology.com/forum/index.php?topic=2110.0

Try adding #ADD_ON_REFRESH=10 to the top of your plug-in page. The "10" is the number of seconds between refresh. That should (if I remember correctly) set the "refresh" in the HTML header for you based on these lines in unmenu.awk (around line 420) if( array_state == "STARTED") { plug_in_refresh_interval = CONFIG["pi-" i "ADD_ON_REFRESH"] ? CONFIG["pi-" i "ADD_ON_REFRESH"] : 0 } else { plug_in_refresh_interval = 0 } # We supply a HTTP header before the first chunk # note, we handle everything here as text/html. http_headers = GetHTTP_Header("text/html", plug_in_refresh_interval, add_on_url )

Apparently, you've made local changes, therefore it is up to you to migrate any changes over the stock myMain_local.conf file... if desired. (Odds are you do NOT want the stock file, so odds are you do not want it to overwrite your copy) Does the downloaded file exist? have you looked at it in the /tmp directory? does it say somethng like "file-does-not-exist" ? or something else? Basically, you need to look at the file downloaded to see what it says. (it is probably an error message and not the expected file) Again, you probably made some local change, as the swapfile package is not downloaded from a 3rd party site, but included as part of the content of the .conf file. No need for you to do anything. You are welcome. As far as S3 sleep, various versions of unRAID have various versions of the Linux kernel... They have various names for the parameters used to control the S3 state. They have changed over the years. As you said, /proc/acpi/sleep directory does not exist in your kernel. Odds are your new kernel does not respond with your motherboard the same as the old. (Either different /proc parameters are now used, OR that capability is not detected with your newer kernel, so they are not created. (and I have no idea which, as S3 sleep has never worked on my hardware... ever.) The buttons on the user-script page where simply what worked on older kernels for some others on the forum. Google is your friend... Once you figure out the newer command needed to put your hardware into S3 sleep, you can share your new S3 sleep commands with others. here. Joe L.

Good that your memory tested OK. It is always the first suspect. What version of unRAID? I suppose it is possible for newer versions to have an issue with malloc/free in (apparently) either the shell or "dd". Nobody else has reported the same issues. In any case, you can use the -r -b and -w options to the preclear script to alter the memory "dd" uses when pe-clearing.

You are welcome. Yes, it is VERY extensible. I wanted to make it easy for non-developers to add "tabs" of their own and have unMENU automatically include them. (I also comment my code far more than most developers. It helps me to figure out what I'm doing years later. ) Joe L.

Absolutely, all the "tabs" are plugins and you can easily clone the User-scripts file (naming it something else) and then editing it to look for whatever file naming pattern you desire for your own scripts. As an example of how to add a new "tab" to do something not normally supplied, look here: http://lime-technology.com/forum/index.php?topic=2595.msg20976#msg20976

only two possibilities I can think of.. 1. you've run out of memory. 2. you've got some defective memory. Are you running a lot of add-ons that might be using all/most of your low-memory? Have you looked at your syslog for other hints of memory related issues? Odds are better that it is #2 with an assertion error. I'd perform a memory check for several cycles, preferably overnight. Joe L.

Short answer... not possible in any way. The passwords are encrypted in both Linux and in windows using a one-way encryption. The encrypted results are compared to the identical encrypted results of your potential password. If both encrypted values match, the passwords matched. In your recollection... (or written on the post-it note under your keyboard ;-) ). It is not stored in plaintext anywhere to un-hide. No... Joe L.

This topic has been moved to User Customizations. [iurl]http://lime-technology.com/forum/index.php?topic=36429.0[/iurl]

initial report (and intermediate SMART reports) is stored in the /tmp directory until preclear finishes and the usual three reports are written to /boot/preclear_reports. If you've not rebooted, you'll find them there in that directory.

I do not see a sector "pending re-allocation" in that smart report. I see one that was detected offline... not exactly the same thing. 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 1 Advice is still valid. If you do not have another copy of your most important files, make a copy elsewhere. unRAID is NOT a backup, it is a way to recover from a single hard-disk failure. Joe L.

You can use it, or not... It is silently ignored on disks over 2.2TB as it has no meaning or purpose on disks using a GPT partition (all disks over 2.2TB use a GPT partition) So... use it, or don't use it... makes absolutely no difference unless the disk is under 2.2TB. Joe L.

Yes, it could easily cause the issues you are having. Most multi-rail power supplies use only one of the rails to power all the hard disks, and they frequently share it with the motherboard as well. The other rails are used for power-hungry video cards used by gamers. Many users have reported issues when going over 6 or 7 drives on a multi-rail supply. Since your PS rails are rated at 20 Amps, and 24 Amps, but we have no way to know which is used for your disks, it might be why you did not have issues until you went to 9 disks. Joe L.

Just what I thought, thanks for confirming. What about the spin retry count? should I read the NEW and OLD value or the RAW? kind of worries me. RAW. It has never had to re-try. (the value is zero) Therefore the normalized value is at its starting value of 100. Apparently, if it fails to spin up a few times, the smart firmware will consider that drive to have failed.

I have precleared several disks 3-4Tb with v 1.13, is it a big problem? Did that version not completely test disks lager than 2.2Tb? The testing was fine, the written pre-clear signature was, at times, not recognized by unRAID as being present.

You did not specify which version of unRAID you are running, but... according to the preclear_disk thread: The current version is 1.15. If you have an older version, please download the newest one. Older versions prior to 1.14 did not have the ability to properly handle larger disks. (larger than 2.2TB) Versions prior to 1.15 did not work properly on 64 Bit unRAID. The current version is 1.15. If you have an older version, please download the newest one. Older versions prior to 1.14 did not have the ability to properly handle larger disks. (larger than 2.2TB) Versions prior to 1.15 did not work properly on 64 Bit unRAID. Assuming you are not on 64 bit unRAID, and not clearing a disk greater than 2.2TB, your disk did not contain all zeros after being written with all zeros. (that is not a good thing) In any case, you might want to download the current version as you are two versions behind. Joe L.

Interesting observation. (and I never gave much thought about the +1 minute, but of course you are correct, it is the next minute, which might only be seconds away.) You are also correct in that it does not look for the top level folder once started. It assumes they are in place and did not consider the issue when initially mounting disks. Yes, the problem is when first starting cache_dirs from the config/go script. Do something like this instead in the "go" script... (assuming cache_dirs resides at /boot/cache_dirs, otherwise, fix the path to where you put it. you'll also need to add whatever " -i sharename" options you like to the line that creates the svcs_restarted script.): mkdir -p /usr/local/emhttp/plugins/cache_dirs/event/ echo "/boot/cache_dirs -q" >/usr/local/emhttp/plugins/cache_dirs/event/stopping_svcs echo "/boot/cache_dirs -w" >/usr/local/emhttp/plugins/cache_dirs/event/svcs_restarted chmod +x /usr/local/emhttp/plugins/cache_dirs/event/stopping_svcs chmod +x /usr/local/emhttp/plugins/cache_dirs/event/svcs_restarted

you'll be fine, as the intermediate post-read serves as the pre-read for the subsequent cycle. Let it continue to completion.

You are trying to thoroughly test the drive, so cutting back on the testing seems a little counter-productive, but yes the preread is the least useful part of the testing, so skipping it shouldn't affect the result and would save time. Actually, it is only when "reading" that un-readable sectors can be identified. If you skip the pre-read, you'll only identify marginal sectors on the post-read, and not have any subsequent "write" to attempt to re-allocate those marginal sectors. When requesting multiple cycles, the post-read of the first/prior cycle is used as the pre-read of the next, so some time is saved and you still get the benefit of the full test. Joe L.

Quite easy to explain... You have Oct 11 14:35:20 unRaid kernel: 8068MB HIGHMEM available. (System) Oct 11 14:35:20 unRaid kernel: 891MB LOWMEM available. (System) You have too many processes running for the amount of memory. (most likely, it is the "low-memory" that you have exhausted.) When this occurs, the kernel attempts to free memory by killing off processes it thinks are idle the longest. Eventually, even that does not work to free enough. Best solution, upgrade to the 64 bit unRAID where you do not have a limit on "low-memory" (although it will require you to migrate to all 64 bit add-ons, as none of your existing addons will be compatible) Good news, most popular plugins have equivalents as 64 bit versions. Since you've run for years, it is possible you've recently installed a new version of newsnab that either needs more memory, or has a memory leak (allocating memory, but not freeing it) or you are downloading a HUGE media file and it is using more memory than usual. Excerpts from your syslog: Oct 11 14:44:55 unRaid kernel: smartctl invoked oom-killer: gfp_mask=0x280da, order=0, oom_score_adj=-1000 Oct 11 14:44:55 unRaid kernel: Pid: 9650, comm: smartctl Tainted: G O 3.9.11p-unRAID #5 Oct 11 14:44:55 unRaid kernel: Call Trace: Oct 11 14:44:55 unRaid kernel: [] dump_header+0x5a/0x199 Oct 11 14:44:55 unRaid kernel: [] ? ___ratelimit+0xb4/0xc8 Oct 11 14:44:55 unRaid kernel: [] oom_kill_process+0x4f/0x2c2 Oct 11 14:44:55 unRaid kernel: [] ? has_ns_capability_noaudit+0x18/0x1f Oct 11 14:44:55 unRaid kernel: [] ? oom_badness+0xd3/0xdd Oct 11 14:44:55 unRaid kernel: [] out_of_memory+0x1f1/0x235 Oct 11 14:44:55 unRaid kernel: [] __alloc_pages_nodemask+0x491/0x52f Oct 11 14:44:55 unRaid kernel: [] do_anonymous_page+0x107/0x220 Oct 11 14:44:55 unRaid kernel: [] handle_pte_fault+0xa5/0x2a9 Oct 11 14:44:55 unRaid kernel: [] handle_mm_fault+0x129/0x138 Oct 11 14:44:55 unRaid kernel: [] __do_page_fault+0x34b/0x366 Oct 11 14:44:55 unRaid kernel: [] ? sys_brk+0xfb/0x12e Oct 11 14:44:55 unRaid kernel: [] ? __do_page_fault+0x366/0x366 Oct 11 14:44:55 unRaid kernel: [] do_page_fault+0x8/0xd Oct 11 14:44:55 unRaid kernel: [] error_code+0x5a/0x60 Oct 11 14:44:55 unRaid avahi-daemon[952]: Disconnected from D-Bus, exiting. Oct 11 14:44:55 unRaid kernel: Out of memory: Kill process 1209 (dbus-daemon) score 0 or sacrifice child Oct 11 14:44:55 unRaid kernel: Killed process 1209 (dbus-daemon) total-vm:3368kB, anon-rss:152kB, file-rss:464kB Oct 11 14:44:55 unRaid kernel: smartctl invoked oom-killer: gfp_mask=0x280da, order=0, oom_score_adj=-1000 Oct 11 14:44:55 unRaid kernel: Pid: 9650, comm: smartctl Tainted: G O 3.9.11p-unRAID #5 Oct 11 14:44:55 unRaid kernel: Out of memory: Kill process 1171 (rpc.portmap) score 0 or sacrifice child Oct 11 14:44:55 unRaid kernel: Killed process 1171 (rpc.portmap) total-vm:2852kB, anon-rss:80kB, file-rss:400kB Oct 11 14:44:56 unRaid kernel: smartctl invoked oom-killer: gfp_mask=0x280da, order=0, oom_score_adj=-1000 Oct 11 14:44:56 unRaid kernel: Pid: 9645, comm: smartctl Tainted: G O 3.9.11p-unRAID #5

Keep an eye on the high-fly-writes. The normalized value has dropped quite a bit and is getting closer to its affiliated failure threshold. It has not failed SMART, but it will be something for you to watch on that drive.

This script is exactly how I solved the same issue you are describing. This script is a different approach to making media players happy (and wife happy as a result) by immediately spinning up all the disks affiliated with a given "user-share" whenever any file or folder within the user-share is accessed. This is NOT a green approach as it will result in more spinning disks, so those trying to minimize power consumption can stop reading now. For those with media players that will not wait for disk spinup, and time-out, and make for a less enjoyable movie watching experience, this might work. http://lime-technology.com/forum/index.php?topic=4858.0 Joe L.

The shellshock fix is very important ONLY if you have access to your server from the internet. If it is only accessible from within your home LAN, then the only risk you face is an attack from members of your family.

The syslog messages are no longer being generated, I know for sure in 6b6, and others have commented that they have been missing for other versions as well. Then the "find-duplicates" in unMENU is useless on these later versions. Use one of the scripts mentioned in the linked thread instead.

1. At this time the best scripts to find the duplicate files are described in this thread: http://lime-technology.com/forum/index.php?topic=35183.0 You should probably run one, and then the other. Both may point you to files needing management. The "find-duplicates" in unMENU will ONLY help if you have duplicate files on multiple disks at the same level in the same directory. (and therefore when browsing user-shares, you only see the file on the lowest numbered disk, the others being hidden) Its purpose is different than either of the two in the thread listed above. i.e. if you have /mnt/disk1/Movies/Photo1.jpg and /mnt/disk2/Movies/Photo1.jpg, only the first file will be visible under /user/Movies/. It will find those. (it uses the "duplicate file" error messages unRAID puts in your syslog to know which files to look for. ) unMENU is compatible with any version of unRAID, but don't look there for your find-duplicates solution. As I said, its script serves a different need. Joe L.