RobJ

Good point, and I've added it. Any more improvements? You had me thinking of a quiet place with empty cabins and no visitors and maybe a private beach, if we could find it!

I've added it to the FAQ: I have software that requires using port 80. How do I change the HTTP port that unRAID uses?

I have software that requires using port 80. How do I change the HTTP port that unRAID uses? First, be certain that's what you really want, as changing the unRAID port should normally be a last resort. It's usually much better to change the port your app needs instead. Docker container ports can usually be remapped. Currently, the only way is to edit your go file, and start emhttp with a different port. The go file is at /boot/config/go if you are editing it in a terminal, at \\tower\flash\config\go if you are editing it from Windows (change 'tower' as needed). Find this line in the go file: /usr/local/sbin/emhttp & And change it to: /usr/local/sbin/emhttp -p ## & Where ## is the new port number you want to use to reach your unRAID server webGUI. Then reboot the server. Don't forget that you will also need to change the location in your browser! Example: set emhttp port to 8080 /usr/local/sbin/emhttp -p 8080 & Reboot your unRAID server, then browse to it on the new port http://tower:8080

Key points from that article: * Smart self-repairing file systems (like ZFS) absolutely require ECC RAM. Dumber file systems, like all of the ones we use, just store your data, not try to check and fix it. Bad RAM is always a bad thing, but if your file system is actively checking and 'fixing' your stored data, then bad RAM can be catastrophic, as it can automatically check your data, corrupt it in memory, detect it's wrong, and write it back to storage, thereby actively and progressively corrupting your data! And with ZFS, if it corrupts the Zpool so that it can't be mounted, you may have lost it ALL! (What you're running ZFS on doesn't matter, whether FreeNAS, unRAID, or anything else.) * ECC RAM is a good thing if you can afford it, no matter what file systems you use. It corrects single bit errors automatically and allows the system to continue, and halts the system if it detects multi-bit errors, before data corruption can occur. Of course, a system halt can result in other damage, but no ongoing damage. * Bad RAM is very serious, whether it's ECC or not. The sooner it is detected and replaced, the better. With ECC RAM, it can cause system halts. With non-ECC RAM, it can cause system crashes and silently corrupted data. I'm going to begin recommending, especially for non-ECC users like most of us, that periodic memory testing be added to our scheduled maintenance. Unfortunately, memory testing has to be done offline, requires a reboot, so it will be disruptive to some. The unRAID boot menu has a Memtest, fine for older machines, but not as good as the updated Memtest from PassMark (requires separate bootable media however). Both are free for personal use. How often it should be done, I don't know, but it seems of the same relative value as parity checks so monthly would be good. Most of us are more likely to do it less than that, perhaps quarterly. I'll add one last point, memory tests must be perfect, not one error is permissible. It doesn't matter how infrequent an error is, if a very long memory test returns even one mistake, then one or more memory sticks need to be replaced. Even one infrequently flaky memory bit can make the system unusable, untrustable. * BACKUPS! Backup, backup, backup! There is no substitute for good versioned backups. Regular backups are important, versioned backups are even better, as they ensure that you can recover from silent data corruption, corruption you may not have detected yet and is therefore being propagated to your backups. * If you don't have ECC RAM, don't even consider file systems like ZFS, you are safer with file systems that don't 'scrub'. This makes me somewhat concerned about BTRFS scrubs, especially attempts to automate BTRFS scrubbing. If it only detects issues, that's one thing, and safer. But if it attempts to automatically correct issues, then ECC RAM should be REQUIRED. I'm afraid that for me, this may add one more to the list of BTRFS concerns. I don't want to worry about whether a scrub could be damaging, instead of helping. * ZFS has a terrific reputation, die-hard fans, but also some serious shortcomings. It requires ECC RAM. It requires MUCH more RAM available to it. And it has absolutely NO recovery tools! Supposedly, it's so good it doesn't need them! Or so they say. If you're ready to buy into that, more power to you, but those of us with years of computer experience will be highly skeptical. These are just my thoughts, I welcome correction

Sorry I was off for a while. The issue is with PHP7 and deprecated functions in the fan speed code. Need to replace these. sweet, do you have a ETA? Never ask a developer for an ETA! (If they give you one, you know you're talking to a new and inexperienced developer.) You get the best results by saying "Since you are such a great developer, I know I'll be very happy with it - whenever it's ready."

I'm sorry I don't understand (I did try!) I added a sentence, to remind them it's probably still excluded. I thought it was only the swap trick that didn't work in 6.2? (which I do need to mention) I guess that is rather integral to the way I've written it though ...

Just my opinion, but I'm not sure a new poll would be much better. If you look back through them, it's really hard not to think they're largely ego driven, clearly not representative. If you've splurged on RAM, or otherwise proud of your RAM purchase, you're more likely to want to mention it. A new poll with the right verbiage could be better, but how useful would it be? A good general recommendation based on extent of VM usage would be more useful, I think. What would be nice, would fill a big hole, is a hardware registry of some sort, collected with user effort, and without personally identifying info. It's proven too hard to maintain a Hardware Recommendations list. It would probably require a special piece of software to both collect the info, and provide access, plus a common persistent storage location. Just ideas - * each major hardware component, with a user grade, plus a clue about how heavy the system usage is: - motherboard, CPU(s), RAM, hard drives, solid state drives, graphics cards, drive controllers, power supply; plus the VM count and Docker container count - user grade of component: --- A : completely satisfactory, even for future expansion if user wanted to --- B : completely satisfactory --- C : it's OK, adequate --- D : works, but not recommended --- F : trash, run away * current system status: - Active - Failed - Replaced - Not using * Optional user ID This would allow others to explore what motherboards are currently being used, and what components work with them. But this will never work without widespread buy in. It would have to be easy and almost automatic. Perhaps if the collection was automatic and tied into something we almost all used, like unRAID itself (means LimeTech would have to develop it) or something Squid has done like Community Apps. Most of the info can easily be collected from the syslog and lspci etc (not grades unfortunately). But there would be enough to be very helpful.

I can't tell you how much I appreciate the time you took to review the current page, and note items needing updating! Thank you very much! I did add the new default path and removed the warning, but I really think the cache path is better. I think it's great that Lime Technology have added a default path for new users, that works irregardless of any cache drive, but I don't know why any knowledgeable user would want to use a long path, less direct than the cache path. The longer one uses extra processing every time it's used, both the extra folders in the path and the FUSE processing. It may not be detectable on fast machines, but the inefficiency will always bother some of us old-timers! Done. Could probably be improved though. Done! Lots of changes and removals. Really need to add more plugins, some day ... Done. Chopped most of it, and the old scripts section that followed. Added more recommendations about it, could possibly do more. Let me know if you see more stuff! I don't doubt that there is more to do, especially more plugins to add.

I think you could add that the disk slot swap only works with v6.0 or v6.1, not with v6.2. Oh my! I've been meaning to do that for a long time, and keep forgetting. Partly I guess because I'll have to rethink how I do it, whether to provide an alternative procedure or ... I think I was also hoping that the problem would just go away, with an update that restored the easy swapping behavior! I'll put it on my incredibly long list of unfinished projects ... It doesn't seem to me to be as easy as just saying you can't do it that way any more.

It's a good idea, and I've added it, for the user to consider. I've also strengthened the warnings, and added words about making sure no other machine attempts a scheduled backup. Let me know if anything else can be improved. (I'm sure a better writer could improve it!)

Squid, I created a stickied thread on Plugin system documentation in the Programming board, and figured you might want to add to it? I've added your template thread, don't know what else you might want. You're welcome to add posts.

Is there documentation for the unRAID plugin system? Unfortunately, the docs on plugin development aren't organized, or in one place. It is scattered around, and no one person is maintaining it. Here's what I found: - How does the plugin system work? Documentation Added (old, and some parts are obsolete, but provides a basic foundation) - Plugin Authors: Changes for 6.1 release - discusses compatibility changes - Important unRAID 6.1 Plugin System Changes - discusses compatibility changes too - New! Version 6.3.0-rc9 Release Notes - important plugin changes for 6.3 - Community Applications plugin - the app store for all plugins; read the note at the bottom of first post - Plugin Templates for CA / Appstore - guidelines for full Community Applications compatibility - Application Template Categorizer plugin - for plugin or Docker template authors - use it! - Programming board (there is a little more info scattered throughout this board for devs) - Per this post, "study existing code and plugins. Also look at scripts in /usr/local/sbin. For example 'emhttp_event' has info on events". - Most new plugin authors start by taking apart a few selected plugins, and copying the basic structures. - Note to prospective plugin developers: always ask yourself first, is this something better suited as a Docker container? Because of better program isolation and fewer dependency issues, developers are strongly encouraged to choose Docker container development over creating another plugin. Support topics for all plugins are found in the Plugin Support board.

For login failures, especially with 6.3.0, go directly to: this post Note: this discussion was split off the 6.2.0 Stable release announcement, in order to continue the discussion of all of the issues users have accessing their unRAID server from Windows stations. It is hoped we can come up with a good troubleshooting document. I've decided to temporarily sticky this, until there's a resultant document. Frank, I'd really love to see all of this plus more collected into a comprehensive document on Windows issues with unRAID, both as to visibility problems (workgroup, local master, etc) and credentials/permissions issues. You've written about some of these several times, would you be interested in putting it all together? I don't know if a wiki page is better, or a long post, first authored by you, to which moderators at least could add to, or perhaps a full thread, moderated to only include posts on the issues but not user support posts. I'd be happy to help any way I can, sticky the result in General Support. You already do have a FAQ entry, it could be expanded, or it could point to the more comprehensive doc(s).

Has anyone come across this? I think everyone was hoping you would think to look back a few days! You know you really should read a little bit before posting.

I suspect there may never have been a direct request for it, few have needed it. And it's not quite as simple as just adding a setting, could be confusing for non-technical users, as they will lose the UI until they also change the server address in their browser (which seems obvious but some users ...). And I believe it will probably require a reboot, as emhttp cannot currently be restarted. Additional help has to be displayed, to lessen confusion for some.

I think Squid's analysis is correct. I noticed that the Recycle Bin is being backed up, which seems unnecessary. The one thing I would change is to increase your spin down delay. Your drives are spinning up and down all day long! I could not see a single period in the day when they were not spinning up and down. From all I understand, that's harder on the drives than just letting them spin. I think a better delay for you would be 2 hours. With that setting, I suspect Disk 3 will never spin down, probably others too.

I took your excellent work above, merged it with the old wiki procedure and johnnie.black's version, and added it to the wiki, as a 6.2 section. Replace A Cache Drive I'd really appreciate it if all those who wrote up or performed the procedure could carefully review the wiki page. I'm very sure it can be improved! I wrote it up before seeing Squid's comments, or wgstark's comments about re-installing Dockers, so I know more notes need to be added.

I have to say that the delayed auto-update mechanisms and notifications are working very well! (I know, rather belated feedback!)

The drive is fine! That usually indicates an issue with the SATA cable or connectors, so I would replace the cable with a good one, and check ALL cable connections (both ends of the cables) for tight connections. It's also possible there was a power glitch. CRC errors just indicate that a corrupted packet was detected, and they're always re-sent. A CRC error does not usually cause a disabled drive. I suspect something else happened, and the evidence may be in the syslog that covered that moment. Maybe there was a BIG power glitch!

yatesey, that's a very different problem, so I think it's best if I move your post to its own support thread, found here: Issue creating bootable drive on Mac

I'm getting an error message " Failed to find user 'avahi' ". What do I do? Why after upgrading to a 6.2 version is my webGUI so slow? Why is my webGUI taking so long between pages? Symptoms: - the error message "Failed to find user 'avahi'", usually in the syslog but may appear on the console too - changing pages in the webGUI will take from 20 to 40 seconds per page - some combination of the following sequence of lines appears over and over in the syslog: For as yet unknown reasons, the internal 'avahi' user is missing from some users unRAID systems, and this avahi user has become more important for the proper functioning of the avahi daemons in 6.2 and later. This missing user results in long timeouts while the avahi daemons try over and over to re-initialize. The solution is to edit the passwd file on your boot flash disk ( /boot/config/passwd ), and add the following 2 lines to it: avahi:x:61:214:Avahi Daemon User:/dev/null:/bin/false avahi-autoipd:x:62:62:Avahi AutoIP Daemon User:/dev/null:/bin/false Then edit the shadow file on your boot flash disk ( /boot/config/shadow ), and add the following 2 lines to it: (this may be needed for proper security) avahi:!:14980:0:99999:7::: avahi-autoipd:!:14980:0:99999:7::: You will need to use a Linux-aware editor to preserve correct Linux style line endings. You can use the built-in mc or nano. It's often easier to use copy and paste in Windows or Mac, just make sure you preserve the Linux style line endings. You may have to reboot for it to take effect, or at least restart the array. This post may be edited further as more info comes in.

Parity checks do not refresh the screen very often, because the act of requesting SMART info (temps etc) is a significant interruption. If you do it too often, you will noticeably affect parity check performance, slow it down significantly. I found that if you set refresh to once per minute, the effect was minimal, acceptable. I have Disk Settings->Tunable (poll_attributes) set to 60. When I manually run a parity check, I change Display Settings->Page update frequency from Regular to Slow (from every 10 seconds to every 60 seconds), and uncheck disable page updates while parity operation is running. I normally run in Regular, and disable page updates during parity ops.

Zeron, you need a donation button, or a 'Buy me a beer' button!

I'm going to suggest starting a new support topic in the General Support board. Permissions issues with Windows are somewhat common, and I'm sure someone will have the answer you need. Be sure to add your diagnostics, see -> Need help? Read me first!

Belatedly responding, in case you ever come back ... You would need to modify it, as it's designed specifically for unRAID array data disks. Might not be hard, but I haven't looked at it in awhile. You would need to tear out the unRAID drive and share paths, and insert your own way of finding your drives.