SRB

Thanks Gacpac, I was getting the same warning and this fixed it.

Just wanted to add my voice to chorus of thank you's. Awesome work guys, everything is working perfectly. Sent from my Mi A2 using Tapatalk

A while ago (unRAID 6.3 days) I was trying to get my server configured to connect to an enterprise proxy for http traffic. Through discussions with LimeTech support, I was advised to add the following to my go config file http_proxy=http://proxyserver:port /usr/local/sbin/emhttp & which is also advised in this thread: Back then it didn't end up working and I was told to wait for the release of unRAID 6.4 since the front-end http server was being changed to nginx. So now that some time has passed I'd figure I'd give it another go, but alas I am still not able to get it working. What's more, I know this is a configuration issue within unRAID because if I create a Win10 VM within unRAID, I can get traffic through the proxy within Windows. Any suggestions on how I can get this working within unRAID? Thanks.

Changed Status to Solved

It appears that my plex container has lost its connection to the internet. After noticing I couldn't access my server through the web app, I rebooted the container through the unraid gui, where it just hangs at [cont-init.d] 10-adduser: exited 0. [cont-init.d] 30-dbus: executing... [cont-init.d] 30-dbus: exited 0. [cont-init.d] 40-chown-files: executing... [cont-init.d] 40-chown-files: exited 0. [cont-init.d] 50-plex-update: executing... Atempting to upgrade to: 1.12.2.4929-29f6d1796 I went into the container itself to see what was up, and found that the last command run was a wget to grab the latest release, however the command never completes. To make sure it wasn't a larger problem, I tested the same wget command outside of the container, which runs just fine. Did something change with the network settings for the container? I haven't touched them in forever (i.e., years). Right now they are

So with the upgrade to 6.4.0 I'm now working on encrypting each of my disks. I did some searching around the forums, and didn't find anything related, but my apologies if I am doing this wrong or if this is answered somewhere else. But, here's the process I'm going through which is forcing me to do a parity check as I convert each disk. Steps: 1. Empty disk to be encrypted. I'm using mc to move all contents of diskX to other disks on the array, 2. Stop array. Change filesystem type of diskX from xfs to xfs - encrypted. 3. Return to start array, however I'm stymied with this: which is peculiar since I didn't shutdown my system. A little more info: I've gone through the process of starting the array, which successfully encrypts the disk and does the parity check. The parity check reports back zero errors corrected. Obviously this doesn't create any problems per se, it just massively increase the time its going to take to convert my entire array.

So I found the root issue of my problem. Like I suspected it wasn't related to unRAID at all. It was a recent update to Bitdefender that did it. However, I haven't figure out how to solve the problem other than uninstalling BD since I am using the free version and it doesn't really let you change much.

Just tried it. Same result

Thanks for the suggestion, but it didn't work.

First off let me start with that I know this is not an issue with unRAID, but rather related to the computer I'm trying to use to access the webgui. However, I've been unable to solve the problem on my own so here I am... Whenever I try to access the unRAID webgui, I get the login prompt but after entering my credentials the page does not load. The issue is not related to any particular browser. Firefox simple leaves me with a blank tab, while Chrome and Edge and give me the following. Now some observations: 1. I know this isn't related to the VPN I use to connect into my home network, as the problem persists even when I am at home connected to my LAN. 2. I know unRAID isn't the culprit, because I get a similar error when trying to access my router's webgui. 3. I know its related specifically to the computers I am using (Windows 10 OS), because I can access the webgui just fine from other computers. Any recommendations on how to fix this would be greatly appreciated. I've tried just about everything short of a fresh install of Windows.

Hey everyone, So problems have ensued with my unraid box since this issue. The public IP address issue with my box has been resolved, however, the random locking up has not. Last night the system had its worst crash, which I am looking to the unraid community for help in identifying the root cause. Here is what happened, bear with me, I apologize for the wall of text. The system had locked up yesterday so I was forced to shut it down uncleanly. I brought the system back online, disabled the smb shares and docker (to disable unnecessary network access) and let a parity check run overnight. However, the system crashed some time during the night, during I suspect the parity check. The terminal output from the crash is below. I was unable to pull diagnostics at this moment since the server was unresponsive. After the crash I turned off the box and turned it back on. Fans turned but no video, no LAN activity, nothing. Tried again, same result. I then powered off, unplugged everything, plugged it back in and it turned on. Bios stopped on the message below. I had to reset the BIOS to default settings, then set the BIOS to boot from the unraid USB, and finally it booted into unraid. Everything seemed normal in unraid at this point. All drives were showing available with no errors. Attached is a diagnostics zip file taken from the first successful reboot. fmrlserv-diagnostics-20170307-1208.zip To me it appeared that the server booted normally here, however the syslog does contain a new error I've never seen before: Mar 7 12:07:15 FMRLSERV kernel: blk_update_request: I/O error, dev fd0, sector 0 Mar 7 12:07:15 FMRLSERV kernel: floppy: error -5 while reading block 0 which the server spits out every 3 minutes. Did I re-enable a ghost floppy disk drive when I reset the BIOS and so I'm getting this error? The server is now 3% into a parity check with FCP running in troubleshooting mode. One other strange observation about the reboot process. Since the crash I've since rebooted the system a few times, and each time I am noticing a message regarding NVRAM (from the BIOS?) that I do not believe I have seen before. See the image below. I am not 100% sure on this since the message flashes very quickly (had to take a video in order to capture the still), but I am fairly certain the message is new. That all being said, I believe my problem is hardware related and I am looking to the community to nail this down. Here the system specs and my thoughts on what could be the problem unRAID 6.3.2 Motherboard: ASUS P5K/EPU CPU: Intel Core 2 Quad Q6600 RAM: 4GB DDR2 - when I first built this server these sticks passed memtest running for approx. 24 hrs. However, I am not ruling them out. I have a new set of sticks currently running memtest in another box which I can swap in if they pass. I plan on letting it run for 48 hrs Data drives: hodge-podge of 14 drives (including parity), mostly WD green and reds 2-4 TB in size. Cache: 240 GB SSD Power supply: Corsair CX 500 - my power supply may be under-powering the system. When I built the system I calculated 500 W would be about the bare minimum I could go, however I had this PSU lying around, I knew it was in good condition and from a reputable brand so I went with it. Do my symptoms indicate I have a power problem? I can swap in a larger power supply (600W), albeit from a less reputable brand (thermaltake). The server primarily serves files via smb, however it does also run 3 dockers: Nextcloud, letsencrypt and mariadb. I have these plugins installed: CA, FCP, Nerd tools, preclear, proftpd, and unassigned devices. Is there any test I can perform to identify if my issues lie with my motherboard, cpu or psu? Would running prime 95 on the system be helpful? Thanks

I really like this idea Squid, would be much less of a headache for me. I think this is the way to go. Cheers

Recently, with the help of the wonderful unRAID community, I discovered that my unRAID system had a public IP. I've since resolved this issue by having my university's IT department re-assign my box to a private network, however this has created a new problem, as now all of my http and https traffic must be handled through my school's proxy server. I've search the forums quite a bit, finding these topics https://forums.lime-technology.com/topic/47562-how-to-add-a-proxy-to-unraid/ https://forums.lime-technology.com/topic/52976-unraid-behind-corporate-proxy-server/ https://forums.lime-technology.com/topic/28753-proxy-configuration/ All of which are trying to do the same thing, but none of which have a solution posted. Has anyone been successful in configuring unRAID to connect to a proxy for http(s) traffic?

Hmmm thanks for pointing this out, I agree this is not good. I guess never realized because I'm most always on my school network. I will get my IT department to reassign the box so unraid is not exposed. If this locking up problem persists after I get this resolved I will post back. Thanks johnathanm and John_M Sent from my SM-G920W8 using Tapatalk

No, however the server is on quite a large LAN (university network) so I took it out just to be on the safe side.

I've been battling this issue for the last several weeks and I have been unable to pinpoint what exactly is causing my unraid machine to become totally unresponsive. Here are my symptoms: - Unresponsive via SSH, putty terminal just sits trying to authenticate forever. It never times out. - Unresponsive via webgui, same as above. Web browser just sits trying to connect forever, never times out. - Cannot login using local terminal. See attached screenshot. The box is alive, so I can enter in my username and password, however, after hitting enter the system just hangs forever trying to authenticate (I'm assuming). Even control+c doesn't do anything. At this point I am forced to shutdown uncleanly. Since this behaviour has happened repeatably, I had the fix common problems troubleshooting mode running during the last lock-up. Attached is the most recent diagnostics zip file. I cannot provide a tail file, since there wasn't one captured when I forced the box to shutdown. I am hoping the experts here can glean some meaning from the logs. One of my big concerns here is when the last diagnostics file was captured: 6:50 AM local time here, however, by my judgement the box became unresponsive around 8:30 AM. I am not certain on exactly when, but there definitely should have been more logs file captured after 6:50 and before I shut it down (since prior to 6:50, a zip file was being captured every half hour). Does that mean that whatever caused my system to lock-up also crippled the fix common problems plugin's ability to capture log files? Any and all help is very much appreciated!

Yeah I'm seeing that by doing some searching on the forums. I think I have an old 10/100 Intel card laying around. I will switch it in and see if the problem persists.

I've been having recent stability issues with my unRaid server. The timing of the problem is leading me to believe its related to upgrading to 6.3.0/6.3.1, but that has yet to be confirmed. The server contains a large amount of experimental data which is being processed by my desktop, with the results being written back to the server. Thus data is constantly streaming from and to the server (think 30 MB/s for 24 hrs straight). However, recently the processing is failing because the network connection to the server is dropping out. This usually causes the server to become unresponsive via the webgui and ssh, and so I'll have to reboot it by lugging a keyboard and monitor down to my basement. Attached is a syslog captured while the processing is running. I'm by no means an expert at interpreting unRaid logs, but these errors caught my eye Feb 9 15:27:52 FMRLSERV kernel: sky2 0000:02:00.0: error interrupt status=0x8 Feb 9 15:27:52 FMRLSERV kernel: sky2 0000:02:00.0: error interrupt status=0x40000008 Feb 9 15:27:52 FMRLSERV kernel: sky2 0000:02:00.0 eth0: rx error, status 0x7ffc0001 length 828 Feb 9 15:27:52 FMRLSERV kernel: sky2 0000:02:00.0 eth0: rx error, status 0x7ffc0001 length 876 Feb 9 15:27:52 FMRLSERV kernel: sky2 0000:02:00.0 eth0: rx error, status 0x7ffc0001 length 1084 Doing some quick googling leads me to believe there is a hardware/driver issue with my onboard LAN adapter, which is Marvell 88E8056 on an Asus P5K/EPU mobo. My hardware configuration has been solid up until now (for approx. 1 year), so I'm inclined to believe its not a hardware failure problem. Any and all help is greatly appreciated. Cheers.

I suppose if I wanted to enforce this, in a way that is fair and avoids squabbles, I'd create a policy of BYOD, Bring Your Own Disk! Then each one uses and writes *only* to their disk. If they want more space, they buy a bigger disk, and replace theirs. No one ever has to deal with anyone else's greed or clutter. This doesn't preclude having other shared spaces, if you choose. To avoid fights, it's always best for each shared space to have only one owner, one 'ruler'. Their space, their rules, even if shared access. True, that would be an excellent way to enforce it. However SATA connections in the system are too valuable to give each roommate their own disk. Much more efficient to throw one large disk in and then split it evenly among the squabblers.

Bumping this as this would be a feature I would use immediately. I'll give you my use case: Server serves media (TV shows and movies) to myself and three other roommates. In addition, we each have our own personal (SMB) user shares that we use for personal data (backups, photos, etc...). To keep things fair, setting a size limit for these shares would be beneficial so that one individual cannot hog the array's capacity. In a perfect world I would just condition my roommates to practice restraint and not throw tons of junk in their personal folders, but you know people can be stupid and/or greedy. I've read around the forums extensively about how this could be done by limiting a share to a disk, but I don't have equal disks of a reasonable size to devote to this cause. I've also seen suggestions to try splitting a disk into a few virtual partitions, but failed to find anyone who implemented it in a bulletproof way. Cheers

I'm trying to get nextcloud working as per the instructions provided here, but I'm running into an issue when trying to configure nextcloud for the first time through its webgui. Specifically, I put in the details of my MariaDB, however I get an error (taken from MariaDB logs) 2016-08-31 10:27:44 47012320705280 [Warning] IP address '172.17.42.1' could not be resolved: Name or service not known 2016-08-31 10:27:44 47012320705280 [Warning] Access denied for user 'root'@'172.17.42.1' (using password: YES) which is strange considering that's not the ip address of my db, it should be 192.168.1.107:3306 (which is what I entered in the database host field). As far as I can tell my MariaDB docker is configured correctly, as I've made sure: 1. Installed MariaDB from linuxserver repo 2. Enabled binary logging 3. Provided a MYSQL_ROOT_PASSWORD Any help with this would be greatly appreciated. * Edit below * Solved this problem after doing some reading up on MariaDB (noob here). Thought I'd post the solution in case someone else runs into the same problem. From the Unraid command line entered the MariaDB container: docker exec -it mariadb bash Login (it should prompt you for root's password) mysql -p Since nextcloud (for whatever reason) was trying to connect from 172.17.42.1, I created a user from this host. I called the user nextcloud CREATE USER 'nextcloud'@'172.17.42.1' IDENTIFIED BY 'password'; Grant the nextcloud user privileges equivalent to root GRANT ALL PRIVILEGES ON *.* TO 'nextcloud'@'172.17.42.1' WITH GRANT OPTION; Then all I had to do was change the username and password in the nextcloud gui and voila! it connected and created the nextcloud db.