JonathanM
-
Posts
16,802 -
Joined
-
Last visited
-
Days Won
66
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Report Comments posted by JonathanM
-
-
17 minutes ago, Can0nfan said:
as far as I know fedora doesn't support samba
https://docs.fedoraproject.org/en-US/Fedora/12/html/Deployment_Guide/s1-samba-mounting.html
-
If you can figure out what changed and what needs to be updated to fix this, I'm sure limetech would be happy to consider modifying unraid to get it to work, as long as the fix doesn't effect bare metal users negatively.
That said, you are pretty much on your own figuring out a solution. There is a small sub community here that runs unraid under ESXI, but there is no official support for doing so.
Limetech's position on running unraid under a hypervisor is pretty much as follows.
They don't actively discourage it, but it's up to you to get it running. Any issues with unraid must be reproduceable while running bare metal in order to get troubleshooting assistance from them.
I suggest you get together with the other people running unraid under ESXI and collaborate with them about this issue.
-
4 hours ago, bonienl said:
Nothing dsngerous in my opinion, in a well behaved system.
Very true. I only said mildly dangerous, as it will work without issue almost always. It's the almost that gets me, and since I very rarely shut down, it makes sense to watch the process to ensure my system is still well behaved.
Others have higher risk tolerance, I prefer to keep an eye on things and not assume all is well until I've verified it to be so.
4 hours ago, bonienl said:To ensure the system can continue, there is a timer built-in and the timer setting must be long enough to allow all services, including Docker and VM to stop in time.
That has not been advertised as well as it should. Occasionally people should time the array stop, and use that information to customize their shutdown time to suit.
Can the array start and stop timing be readily harvested from log files? If so, I think it would be useful to keep a separate saved list similar to parity check statistics, that way you could look back in the history to find how long it generally took the array to start and stop.
Also, a notation that the previous shutdown was unclean BECAUSE of an elapsed timer and not a hard crash would be useful, especially in the OP's case. If the timer kills the array, it should notify you.
-
1 hour ago, Jerky_san said:
I simply rebooted via the reboot option in the GUI
Yeah, don't do that.
Stop the array first, then hit reboot.
The forced shutdown currently in place is mildly dangerous in my opinion, and should only be used in an emergency, or by a power failure signal by the UPS.
-
Try to replicate the state of the system before you hit reboot, and hit stop instead. Time how long it takes for the array to finish stopping.
-
6 minutes ago, Nosirus said:
still no VM/Docker outside the array ?
That's not likely to happen any time soon.
-
Having array drives attached via USB is not ideal. It will work when everything is healthy, but error handling and recovery is sub par, and smart reporting can be problematic.
-
6 hours ago, phbigred said:
Depends on what you use it for. Been overclocking with Unraid for years. Tell me you don't overclock your ram to get timings reported on the sticks... Difference in Watts pull and overclockability of AMD within margins and tight CPU OC makes it a completely safe bet in my case. I run 2 gaming VMs off this with CPU pinning and GPU and USB PCI passthrough.
Overclocking by definition means running above specified safe limits. Safe being defined as what the manufacturer of the part recommends for a normal lifespan.
Running out of spec may initially work fine, but as parts age, things can change. Overclocking can accelerate that aging process, causing premature failure. Servers are designed to be reliable 24/7/365 for years on end. Overclocking is not a good idea if you wish to retain that reliability for the long term.
-
1
-
-
3 minutes ago, bonienl said:
The source of the problem is the firewall.
If somebody decides to block any ping request on his firewall, no fail-over will ever work.
Not just ANY ping request, just 8.8.8.8. All I ask is a way to keep updates working while not pinging a google address.
-
1
-
-
How about a compromise. Add a second user configurable field that it will fail over and try if 8.8.8.8 doesn't answer for whatever reason.
-
1 hour ago, bonienl said:
The plugin update function of unRAID however has a built-in Internet alive check, which is done by pinging 8.8.8.8, before it downloads files.
Please, please, please make that configurable, even if we have to manually change an entry in a file. I do NOT want basic functionality hardcoded to an external IP we don't control, and we have no way of changing.
I realize it works properly 99.999% of the time, but can we at least have it be changeable if needed?
-
3 minutes ago, eschultz said:
The 'bug' here is if you leave "Battery level to initiate shutdown (%):" or "Runtime left to initiate shutdown (minutes):" boxes empty (instead of 0) then it uses some random 5000 value ... which of course will tell unRAID to shutdown right after running on batteries since UPS at 100% < 5000
So are you going to change to empty = 0 on future releases for those values?
/mnt/user dissappeared
in Stable Releases
Posted
lose the /mnt/user in the remote path