xamindar

Upgraded to the 6 beta finally and love the new look. Here are a couple of issues I have noticed so far: -the dark theme does not show grayed out text fields in a way that you can know they are unusable. -I zapped the partition table of an empty array drive, changed it's filesystem to btrfs in the unraid interface and then started the array. As expected I needed to format it which I did. Everything came online and looks good EXCEPT....parity is still showing as "valid" which seems incorrect. Sure enough, I started a parity check and millions of errors being corrected so it looks like it is basically rebuilding parity. Shouldn't it state parity is invalid after a filesystem change in such a way? If someone doesn't run a check they may assume parity is good when it is not.

Is this something unraid is being designed to support down the line? Are its btrfs volumes set up as a subvolume by default to allow for snapshotting? I guess I'll find out soon enough as I am preparing my unraid system for the 6 upgrade. Will probably start eith making the cache drive btrfs.

Usually it's the speed of the bluray drive (about 2x speed) that is the bottleneck. Is it much faster when you rip directly to your local hard drive? Sent from my A510 using Tapatalk

First, I don't see this as a bug in the webGui (both SF and Dynamix). It is a design decision (flaw?) in emhttp to start background disk activity upon each HTTP request made to it. That means that any button click you do in the GUI causes HDD activity. In the stock webGui this is circumvented by making it completely passive, meaning only when the user clicks on something there is interaction with emhttp. That's why people should not do a frequent page fresh as it interferes with a parity check. Second, Dynamix can be set to "passive" or "disabled" which stops all background HTTP requests and basically turns into the same manual behavior as the stock webGui. This explains why people see a difference in parity check speed when choosing a different page refresh mode in Dynamix. Why the parity speed is different with Dynamix opened in passive or disabled mode, I can't explain. Was this tested with the stock webGui as well, I expect exactly the same results... Thank you for the clarification on this issue. I wasn't aware that emhttp was actually causing it with each request made. Still, you have created an amazing gui replacement. Thank you. Sent from my A510 using Tapatalk

This parity check slow-down was a problem with simplefeatures as well. Can you please fix this bug? The parity slow-down is the most annoying thing about these custom web guis. Sent from my A510 using Tapatalk

Lol, ambient temperature will never get high enough to damage a hard drive, unless your house is on fire. Sent from my A510 using Tapatalk

Why does it matter what the temp is when they are spun down? They wont be generating any heat so there is no point. Sent from my A510 using Tapatalk

Note that the min free space setting is only checked when first creating a file. Therefore the min free space setting needs to be large enough to allow for the largest file that you might create (and if you might be doing several in parallel the sum of them). If you run out of space on the drive after creating the file as you write it there is no automatic fail-over to the array drives and you get an error about running out of space. I think you may have missed the example in my first post. Cache only has 17GB free, min free space is set to 30GB. Since the cache drive has less than the minimum, why is it still letting me create new files on the cache drive (in my example, the new bluray rip). That is what happens for me once the free space on the cache drive falls below the min free space value. Ok, then this is not happening for me, at least for the cache drive. As I posted above, min free space for the cache drive is set to 30GB and there is currently onlt 17GB available on the cache drive. If I attempt to write a new file it is still written to the cache drive instead of directly to the array in this case. I'm on unraid 5.0 so I am confused that mine is acting different than yours. I'm not using any split levels on the shares, should I be? There has got to be some option set somewhere else preventing my min free space setting from working. I did install the Dynamix web gui, could that be causing the issue?

I have a problem with my cache drive filling up. It is only 120gb and can easily fill up if I transfer too much data over in one day. For example, I currently only have 17GB of space left on my cache drive. I start ripping a 37GB bluray to my multimedia user share which is set to use the cache drive. Makemkv warns me that there is only 17GB left on the share, I continue, and the cache drive eventually fills up causing the rip to fail. First of all, why is the user share reporting my cache drive available space instead of the entire share available space (which is several terrabytes)? Second, I have the cache disk "min free space" setting set to 30GB but this seems to be ignored or not do what I want. What am I doing wrong? It would seem to make more sense to me for unraid to write the next file directly to the array if the cache drive gets almost filled. Is there any way to do this? Or do I just need a bigger cache drive (or manually run the mover to make more cache space when it gets full)?

I have Dynamix up and running for weeks, and no emhttp crashes and - as the developer - I do a lot with Dynamix webGui and optional plugins. Are you running other plugins which are memory hungry and eventually let emhttp starve ? One workaround to prevent emhttp from being killed by the OS, is to put the following in your 'go' script (and run manually): # Set webGUI never killed off echo -1000 > /proc/$(pgrep -f /usr/local/sbin/emhttp)/oom_score_adj Thanks a lot! I'll give that a try. I am running btsync and dropbox plugins which I can see taking up a lot of memory (8 gigs in this box though). But why can't I re-launch emhttp once it is killed? It just segfaults which makes me think something other than OOM is the cause.

Love this web gui and good job. But unfortunately, it causes emhttp to eventually crash just like simple features used to do back on the pre-5.0 versions of unraid. And once it crashes, it can not be restarted without a reboot as it seg faults until then.

I have two issues that are becoming annoying: First, when I start writing to a share that is spun down and it has to spin up, the write times out and fails before the drive finishes spinning up. Is there any way to increase cache/time it waits before timing out? Why can't unraid just accept the write and then flush it all do disk once the drive is ready? Second, If I'm streaming a movie to another machine while one of the other unraid drives needs to spin up, the stream stops until that other drive finishes spinning up. Why would a completely different drive affect the current read from an already active drive?

Are you using mixed case? If so, use only lower case letters. Linux doesn't allow mixed case for unix ids as far as I know so no, I am not. All ids I create are lower-case. I removed the new gui and am back on stock but still unable to add any additional users. OK nevermind. It wasn't liking something in the description field. I left it blank and it worked.

I am unable to add any new users from the users tab in unraid. Anyone know what might be wrong? I am using the upgraded gui if that matters.

Bad flash card maybe? Sent from my A510 using Tapatalk 4

might want to check that drive. Linux in general will remount a drive read only if there are too many errors reported. Sent from my SGH-T889 using Tapatalk 2

Thanks for the pointers. It's about time I set identical username and passwords for all my machines. Sent from my SGH-T889 using Tapatalk 2

Ugh, after rebooting this old winXP laptop it was able to connect. Still prompted for a password for some reason but it worked. My other (more updated) computers are having no issues.

I just upgraded to 5.0 final and figured I would make it a fresh start by formatting the usb and installing everything one at a time. I just barely got it up, added a user, and started setting all the shares to "share" level security as I thought that's what I wanted. I was unable to connect to the server after that as it is not accepting the user/password I have set up. So now I changed all the shares back to "public" but the password prompt is still comming up when I try to browse the server. Why is it not accepting the user's password and why is it still prompting for a password even after setting all shares back to public? It isn't even letting me see the shares as it prompts for a password when click on the server. Has anyone experienced this at all? Thanks for any help.

Just upgraded from rc11 to 5.0 final. Hopefully this resolves my "Stale file handle" issue with NFS that I was having almost weekly with rc11. Love the look so far with the new web gui. That's why they are optional.

Lol you are joking, right? The whole reason for cache_dirs is to prevent disc spinup. Disable cache_dirs and you will have your machine set how you want.

Yes, but it only does it based on the temperature of the hard drives you specify in the script if that is what you want. Linux calls it PWM no matter which type you have, 3 or 4 pin. I'm using the script with 3 pin fans. No you don't have to start the service, just make sure the modules it found are loaded on boot up.

Yes, just build the f71882fg module and add it. I personally run unraid on a full arch linux distro and had to build my own kernel for it anyway. Just make sure you build from the same kernel source version that is used in unraid. I don't know why limetech doesn't just include all these modules in unraid, they don't take up very much space and make no difference on how it runs unless they are loaded. Some of the choices in the unraid kernel build seem pretty daft.

Yeah, it doesn't look like there is a driver for your sensor chip yet. The closest I can see in the 2.6.36 kernel is this driver. But it doesn't mention 8721 which I assume you have based on the ID. ???????????????????????? ITE IT87xx and compatibles ???????????????????????? ? CONFIG_SENSORS_IT87: ? ? ? ? If you say yes here you get support for ITE IT8705F, IT8712F, ? ? IT8716F, IT8718F, IT8720F and IT8726F sensor chips, and the ? ? SiS960 clone. ? ? ? ? This driver can also be built as a module. If so, the module ? ? will be called it87. ? ? ? Is this your chip? If so, it definitely isn't supported yet. From this it seems like a strange, rare chip only ASUS uses.

Not necessarily, it may just mean there is no driver in the Linux kernel for your chip (or you have none, unlikely with recent hardware). If sensors-detect didn't say "yes" to anything as you went through it then there probably isn't any driver for your hardware. You could possibly try a full slackware or any more recent linux and see if there is a driver (module) for it in more recent kernels.