Frank1940

Fill in the blanks for a DNS server addresses. You can use 8.8.8.8 and 8.8.4.4 as they are Google's DNS servers and they work anywhere in the world.

So the link is actually: https://hub.docker.com/r/binhex/arch-krusader/builds/

The Link to the website to get the proper version number (i.e., <verisonyouwant> ) does not work. Probably a simple update of the link is required.

Try using the Search Engine, Duck Duck Go, to search for street address to geographical coordinates. The user might have to use a manual entry method but it should be a one time thing.

How about HERE:

Both of your posts in both threads are a bit out of the wild blue wonder. (You should really have started a new thread...) The basic question that always has to be asked for any SMART 199 errors, it this: Is the count continuing to increase? The reason being that this counter can never be reset. The Error itself is a nuisance more than anything else. The error will always be automatically fixed by requesting that the data be resent until CRC code is correct. The only real problem is that it slows down the data transfer rate. If it is an occasional error, this delay is insignificant in the bigger picture. Unfortunately, you will get a warning every time unRAID reboots (and, as I recall, with the periodic status reports) unless you turn them off. (Where to do this at the moment escapes me but I think it was on the Dashboard page...)

What you didn't tell us is what you are using your server for. If it is a basic server, you probably won't have any problems. The more Plugins, Dockers and VM's you have, the more likely you are to encounter a problem. I would suggest that you stop everything you can before doing an upgrade. Then make a backup of the flash drive before you do the upgrade. On the first boot, you might want to select the 'Safe Mode' (It is a boot option). This will allow you to see if the basic server functions are working normally. Check to make sure that all of the drives are assigned correctly (This should really not be a problem). Now try the normal boot. Hopefully, everything will be working normally. Check for updates for plugins and Dockers. Start up things one at a time to see that each one works before going on to the next

@binhexDid the update on my Server and no problems. While you are online, are you aware of this: https://www.askwoody.com/ Apparently, Chrome beginning with version 68 (releasing today) is going to be marking all websites that aren't using https as insecure. Any idea of what this will mean for things like Krusader which use an insecure browser window to run in?

To uninstall: go to Settings >>> NerdPack Then look for atop in the list of apps. Then determine if you installed. IF you did, you should be able to uninstall it on that same line with the toggle slide to 'off'. If some other app installed it, you may (should?) be able to see which one it did it.

try this command: ls -al /mnt/cache/appdata/binhex-krusader/krusader I have the latest version of Installed and I came from the 'old' version. If that directory does not exist something must be awry in your install. Make sure that you can create a file in the /mnt/cache/appdata directory. Along the path to this directory make sure that that the directory owners/users are nobody:users The only other thing I can think of. Did you install a cache drive since you first installed crusader? The reason that I ask this is that in the back of my mind, I seem to recall that making a share 'cache only' will cause the share to be removed from the array entirely. This is what My settings look like. Notice the AppData Config Path variable ---- Do you have this?

You should be able to do it in the Terminal window included in the latest versions of unRAID GUI. (So many folks don't seem to remember that it is there. SSH is now only needed when the GUI is unavailable.)

You got hundreds of entries like this: Jul 8 04:30:02 Tower sshd[20587]: Accepted publickey for root from 192.168.178.34 port 58842 ssh2: RSA SHA256:NlDaBhofPoWmFOvqcBxxPRT3HmcRZFEqIdAma/CLoBQ Jul 8 04:32:43 Tower sshd[20587]: Received disconnect from 192.168.178.34 port 58842:11: disconnected by user Jul 8 04:32:43 Tower sshd[20587]: Disconnected from user root 192.168.178.34 port 58842 Jul 8 04:32:43 Tower sshd[1812]: Accepted publickey for root from 192.168.178.34 port 58844 ssh2: RSA SHA256:NlDaBhofPoWmFOvqcBxxPRT3HmcRZFEqIdAma/CLoBQ Jul 8 04:32:59 Tower sshd[1812]: Received disconnect from 192.168.178.34 port 58844:11: disconnected by user Jul 8 04:32:59 Tower sshd[1812]: Disconnected from user root 192.168.178.34 port 58844 Each time it seems like the port number increases. I am not expert but it looks like you are being probed for a way into your system...

For a start, go to Tools >>> Diagnostics and then upload the resulting Diagnostics file with your next post.

If you feel the click, the connector is working the way it was designed. If you overclocked the system to improve the efficiency of the mining operation, the consensus has been that you should never be overclocking a server because of reliability concerns.

The next time after this events occurs, go to Tools >>> Diagnostics and upload the resulting file.

I believe that only of two of the ports use the Marvell controller. (At least, this is typical and generally these are the two highest ones.) One more thing to check if your SATA cables have metal latches. First, read this article: https://support.wdc.com/knowledgebase/answer.aspx?ID=10477 While it only pertains to WD hard disks, whatever the reasons were for the change, they might have caused other disk manufacturers to do the same thing. The way to check is to pull gently on the SATA data connector on the HD. You should feel a (slight) resistance as you pull on the connector. If you can feel none, the connector does not have the internal 'bumps' and is just 'floating inside of the housing. Of course, if the metal latch is locking onto the shroud, It won't even move!

I have never heard of anyone having a heat problem with them in an unRAID server. Yes, normally they are used in a forced air cooled rack but the packing (and power) density is far beyond what the typical unRAID server will experience. If you keep the HD's temperatures from exceeding the mid 40'sC, you should be OK. Remember that the air flow should come across the HD's first and be forced out of the case behind them. (You don't want to have any fans blowing in as you might with those video cards installed!) Plus, the LSI card will only draw about 15W in the worst case condition with the nominal power around 8W.

unRAID tracks disks by serial numbers so everything should end up correctly assigned to the right slots. BUT, I would still grab a quick screen shot of the assignments. It is just good insurance. BTW, today LSI based SATA cards are the recommended choice. You can pickup an eight port one on E-Bay between $50US and $100. Try to avoid the counterfeit Chinese ones. Just be sure you go with a reputable supplier and don't base your purchase choice strictly on price. Here is a link to what you should be looking from from @johnnie.black: https://lime-technology.com/forums/topic/69018-sata-controller-replacement-question-and-advice/?tab=comments#comment-630097

I have delayed replying to you as I am not much of Guru in this area. But your two SDD's seem to be connected to SATA ports 5 and 6. There are a lot of errors associated with these two ports near the end of your syslog. I also suspect that those two ports are also using the Marvell Controller chip (Marvell chips have been implicated in a lot of issues over the past few years.) Plus, you indicate that things got better when you turned off the eSATA port. Plus the number of CRC errors are exactly 99 for both disks. This would normally not be expected if it were a problem with cables. I would like to suggest that you move those two SDD drives to the two of the other four SATA ports and lets see what happens. Note that CRC errors are not fatal. They simply require that the data be resent and, thus, have a small effect on performance.

Go to Settings >>> Identification >>> Management Access

Here is a link to the thread for that preclear script: https://lime-technology.com/forums/topic/30921-unofficial-faster-preclear/ I would start at the end of the thread and read carefully moving backward...

I am sorry that I can't help you beyond what was there. In the distant past, I did use @Joe L.'s script wit this plugin but I don't remember where I put it. The support of this plugin has been hit-and-miss for quite some time. I have the feeling that life has gotten in the way and he can't devote the time necessary to to provide more assistance. I also suspect that his preclear script is not a stand-alone script but included in one of the other files. I also don't recall what happened when I used @Joe L.'s as to whether I had to choose it or it was just used automatically. (I suspect the latter since the instruction tell us to rename the script to a generic name.)

From the first post in this thread. Put it in the /config/plugins/preclear.disk folder on the flash drive.

@gfjardim, has this issue been addressed yet? Jul 10 17:56:48 Rose rc.diskinfo[8325]: SIGHUP received, forcing refresh of disks info. Jul 10 17:56:48 Rose rc.diskinfo[8325]: PHP Warning: Use of undefined constant ID_MODEL - assumed 'ID_MODEL' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 470 Jul 10 17:56:48 Rose rc.diskinfo[8325]: PHP Warning: Use of undefined constant SERIAL_SHORT - assumed 'SERIAL_SHORT' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 470 Jul 10 17:56:51 Rose rc.diskinfo[8325]: SIGHUP received, forcing refresh of disks info. Jul 10 17:56:51 Rose rc.diskinfo[8325]: PHP Warning: Use of undefined constant ID_MODEL - assumed 'ID_MODEL' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 470 Jul 10 17:56:51 Rose rc.diskinfo[8325]: PHP Warning: Use of undefined constant SERIAL_SHORT - assumed 'SERIAL_SHORT' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 470 Jul 10 17:56:51 Rose rc.diskinfo[8325]: SIGHUP received, forcing refresh of disks info. Jul 10 17:56:53 Rose rc.diskinfo[8325]: PHP Warning: Use of undefined constant ID_MODEL - assumed 'ID_MODEL' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 470 Jul 10 17:56:53 Rose rc.diskinfo[8325]: PHP Warning: Use of undefined constant SERIAL_SHORT - assumed 'SERIAL_SHORT' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 470 While it is not a 'show stopper' at this point, it could become a major problem with the next release of PHP.

Same type of problem but mine look like this: Jul 10 17:56:48 Rose rc.diskinfo[8325]: SIGHUP received, forcing refresh of disks info. Jul 10 17:56:48 Rose rc.diskinfo[8325]: PHP Warning: Use of undefined constant ID_MODEL - assumed 'ID_MODEL' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 470 Jul 10 17:56:48 Rose rc.diskinfo[8325]: PHP Warning: Use of undefined constant SERIAL_SHORT - assumed 'SERIAL_SHORT' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 470 Jul 10 17:56:51 Rose rc.diskinfo[8325]: SIGHUP received, forcing refresh of disks info. Jul 10 17:56:51 Rose rc.diskinfo[8325]: PHP Warning: Use of undefined constant ID_MODEL - assumed 'ID_MODEL' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 470 Jul 10 17:56:51 Rose rc.diskinfo[8325]: PHP Warning: Use of undefined constant SERIAL_SHORT - assumed 'SERIAL_SHORT' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 470 Jul 10 17:56:51 Rose rc.diskinfo[8325]: SIGHUP received, forcing refresh of disks info. Jul 10 17:56:53 Rose rc.diskinfo[8325]: PHP Warning: Use of undefined constant ID_MODEL - assumed 'ID_MODEL' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 470 Jul 10 17:56:53 Rose rc.diskinfo[8325]: PHP Warning: Use of undefined constant SERIAL_SHORT - assumed 'SERIAL_SHORT' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 470