tomorrowsman

I did see this in the log, with .34 being my local machine: Mar 1 10:39:11 Tower rpcbind[20815]: connect from 192.168.4.34 to getport/addr(mountd) Mar 1 10:39:11 Tower rpcbind[20816]: connect from 192.168.4.34 to getport/addr(nfs) Mar 1 10:39:11 Tower rpcbind[20817]: connect from 192.168.4.34 to getport/addr(nlockmgr) Mar 1 10:39:11 Tower rpc.mountd[1786]: refused mount request from 192.168.4.34 for /unVideo (/unVideo): unmatched host Mar 1 10:39:11 Tower rpc.mountd[1786]: refused mount request from 192.168.4.34 for /unVideo (/unVideo): unmatched host

I had to move to a different PLEX docker last night due to the depreciation of the one I was using. I moved to the official Plex docker. All seems fine with Plex this morning, but out of nowhere I can no longer access my server -- I had it mapped as a network drive in Windows 10, but today, poof, gone, and doesn't even show up as available to re-map. I can't find anything online that explains if this is due to Windows, Plex, unRaid, or all of the above just being inscrutable at my expense. Any thoughts?

I rebooted PLEX and checked the logs, and you can see where there's definitely a snag: ErrorWarningSystemArrayLogin *** Running /etc/my_init.d/00_regen_ssh_host_keys.sh... *** Running /etc/my_init.d/10_syslog-ng.init... Dec 5 03:48:08 Tower syslog-ng[13]: syslog-ng starting up; version='3.5.6' Dec 5 03:48:09 Tower syslog-ng[13]: EOF on control channel, closing connection; *** Running /etc/rc.local... *** Booting runit daemon... *** Runit started as PID 19 Dec 5 03:48:09 Tower cron[24]: (CRON) INFO (pidfile fd = 3) Dec 5 03:48:09 Tower cron[24]: (CRON) INFO (Running @reboot jobs) 6 10000 /config/Library/Application Support 10000 6 10000 /config/Library/Application Support 10000 6 10000 /config/Library/Application Support 10000 6 10000 /config/Library/Application Support 10000 6 10000 /config/Library/Application Support 10000 [Ad Infinitum]

I just had to rebuild unRaid, and I did indeed see the notes to move all to xfs; in fact, md4 is brand newly to xfs. The others were pending this weekend, but now PLEX is hosed, and I can't figure out how to rebuild it. Is there an easy way to un/reinstall PLEX in the docker? I've never had to before, and would rather not, but whatever needs to be done and all.... Diagnostics attached! tower-diagnostics-20181204-1943.zip

I got my unRaid server rebuilt, and got everything backed up, but PLEX (via Docker) will not start. I restarted PLEX, installed the latest version, but still getting 'Connection Refused' errors. I checked my unRaid logs and I have a lot of this, which I do not understand; any thoughts? Dec 4 02:12:57 Tower kernel: REISERFS warning (device md1): jdm-20002 reiserfs_xattr_get: Invalid hash for xattr (system.posix_acl_default) associated with [3 140584 0x0 SD] Dec 4 02:12:57 Tower kernel: REISERFS warning (device md1): jdm-20002 reiserfs_xattr_get: Invalid hash for xattr (system.posix_acl_default) associated with [3 140584 0x0 SD] Dec 4 02:13:25 Tower kernel: REISERFS warning (device md1): jdm-20002 reiserfs_xattr_get: Invalid hash for xattr (system.posix_acl_default) associated with [3 140584 0x0 SD] Dec 4 02:13:25 Tower kernel: REISERFS warning (device md1): jdm-20002 reiserfs_xattr_get: Invalid hash for xattr (system.posix_acl_default) associated with [3 140584 0x0 SD] Dec 4 02:13:25 Tower kernel: REISERFS warning (device md1): jdm-20002 reiserfs_xattr_get: Invalid hash for xattr (system.posix_acl_default) associated with [3 140584 0x0 SD] Dec 4 02:13:26 Tower kernel: REISERFS warning (device md1): jdm-20002 reiserfs_xattr_get: Invalid hash for xattr (system.posix_acl_default) associated with [3 140584 0x0 SD] Dec 4 02:13:26 Tower kernel: REISERFS warning (device md1): jdm-20002 reiserfs_xattr_get: Invalid hash for xattr (system.posix_acl_default) associated with [3 140584 0x0 SD] Dec 4 02:13:26 Tower kernel: REISERFS warning (device md1): jdm-20002 reiserfs_xattr_get: Invalid hash for xattr (system.posix_acl_default) associated with [3 140584 0x0 SD] Dec 4 02:15:44 Tower kernel: REISERFS warning (device md1): jdm-20002 reiserfs_xattr_get: Invalid hash for xattr (system.posix_acl_default) associated with [3 140584 0x0 SD] Dec 4 02:15:44 Tower kernel: REISERFS warning (device md1): jdm-20002 reiserfs_xattr_get: Invalid hash for xattr (system.posix_acl_default) associated with [3 140584 0x0 SD] Dec 4 02:15:44 Tower kernel: REISERFS warning (device md1): jdm-20002 reiserfs_xattr_get: Invalid hash for xattr (system.posix_acl_default) associated with [3 140584 0x0 SD] Dec 4 02:15:46 Tower kernel: REISERFS warning (device md1): jdm-20002 reiserfs_xattr_get: Invalid hash for xattr (system.posix_acl_default) associated with [3 140584 0x0 SD] Dec 4 02:15:46 Tower kernel: REISERFS warning (device md1): jdm-20002 reiserfs_xattr_get: Invalid hash for xattr (system.posix_acl_default) associated with [3 140584 0x0 SD] Dec 4 02:15:46 Tower kernel: REISERFS warning (device md1): jdm-20002 reiserfs_xattr_get: Invalid hash for xattr (system.posix_acl_default) associated with [3 140584 0x0 SD] Dec 4 02:18:58 Tower kernel: REISERFS warning (device md1): jdm-20002 reiserfs_xattr_get: Invalid hash for xattr (system.posix_acl_default) associated with [3 140584 0x0 SD] Dec 4 02:18:58 Tower kernel: REISERFS warning (device md1): jdm-20002 reiserfs_xattr_get: Invalid hash for xattr (system.posix_acl_default) associated with [3 140584 0x0 SD] Dec 4 02:18:58 Tower kernel: REISERFS warning (device md1): jdm-20002 reiserfs_xattr_get: Invalid hash for xattr (system.posix_acl_default) associated with [3 140584 0x0 SD] Dec 4 02:19:01 Tower kernel: REISERFS warning (device md1): jdm-20002 reiserfs_xattr_get: Invalid hash for xattr (system.posix_acl_default) associated with [3 140584 0x0 SD] Dec 4 02:19:01 Tower kernel: REISERFS warning (device md1): jdm-20002 reiserfs_xattr_get: Invalid hash for xattr (system.posix_acl_default) associated with [3 140584 0x0 SD] Dec 4 02:19:01 Tower kernel: REISERFS warning (device md1): jdm-20002 reiserfs_xattr_get: Invalid hash for xattr (system.posix_acl_default) associated with [3 140584 0x0 SD] Dec 4 02:31:05 Tower kernel: mdcmd (91): spindown 4 Dec 4 02:33:39 Tower kernel: mdcmd (92): spindown 0 Dec 4 02:33:40 Tower kernel: mdcmd (93): spindown 3 Dec 4 06:52:06 Tower kernel: REISERFS warning (device md1): jdm-20002 reiserfs_xattr_get: Invalid hash for xattr (system.posix_acl_default) associated with [3 140584 0x0 SD] Dec 4 06:52:06 Tower kernel: REISERFS warning (device md1): jdm-20002 reiserfs_xattr_get: Invalid hash for xattr (system.posix_acl_default) associated with [3 140584 0x0 SD] Dec 4 06:52:06 Tower kernel: REISERFS warning (device md1): jdm-20002 reiserfs_xattr_get: Invalid hash for xattr (system.posix_acl_default) associated with [3 140584 0x0 SD] Dec 4 06:52:09 Tower kernel: REISERFS warning (device md1): jdm-20002 reiserfs_xattr_get: Invalid hash for xattr (system.posix_acl_default) associated with [3 140584 0x0 SD] Dec 4 06:52:09 Tower kernel: REISERFS warning (device md1): jdm-20002 reiserfs_xattr_get: Invalid hash for xattr (system.posix_acl_default) associated with [3 140584 0x0 SD] Dec 4 06:52:09 Tower kernel: REISERFS warning (device md1): jdm-20002 reiserfs_xattr_get: Invalid hash for xattr (system.posix_acl_default) associated with [3 140584 0x0 SD] Dec 4 10:52:07 Tower kernel: REISERFS warning (device md1): jdm-20002 reiserfs_xattr_get: Invalid hash for xattr (system.posix_acl_default) associated with [3 140584 0x0 SD] Dec 4 10:52:07 Tower kernel: REISERFS warning (device md1): jdm-20002 reiserfs_xattr_get: Invalid hash for xattr (system.posix_acl_default) associated with [3 140584 0x0 SD] Dec 4 10:52:07 Tower kernel: REISERFS warning (device md1): jdm-20002 reiserfs_xattr_get: Invalid hash for xattr (system.posix_acl_default) associated with [3 140584 0x0 SD] Dec 4 10:52:07 Tower kernel: REISERFS warning (device md1): jdm-20002 reiserfs_xattr_get: Invalid hash for xattr (system.posix_acl_default) associated with [3 140584 0x0 SD] Dec 4 10:52:07 Tower kernel: REISERFS warning (device md1): jdm-20002 reiserfs_xattr_get: Invalid hash for xattr (system.posix_acl_default) associated with [3 140584 0x0 SD] Dec 4 10:52:07 Tower kernel: REISERFS warning (device md1): jdm-20002 reiserfs_xattr_get: Invalid hash for xattr (system.posix_acl_default) associated with [3 140584 0x0 SD] Dec 4 10:52:10 Tower kernel: REISERFS warning (device md1): jdm-20002 reiserfs_xattr_get: Invalid hash for xattr (system.posix_acl_default) associated with [3 140584 0x0 SD] Dec 4 10:52:10 Tower kernel: REISERFS warning (device md1): jdm-20002 reiserfs_xattr_get: Invalid hash for xattr (system.posix_acl_default) associated with [3 140584 0x0 SD] Dec 4 10:52:10 Tower kernel: REISERFS warning (device md1): jdm-20002 reiserfs_xattr_get: Invalid hash for xattr (system.posix_acl_default) associated with [3 140584 0x0 SD]

Wow, looks like I picked a bleeding edge dud all those years ago. Is there a wiki of PLEX-friendly drives?

Starting a bit over a week ago, PLEX became nearly unresponsive around the same time unRaid flagged one of my drives as red; I swapped out the drive, upgraded my parity drive, updated my OS, made sure PLEX was up to date, made sure my GB network connection was still operating as it should, everything I could think to do, yet my server remains very slow (e.g., just opening folders takes a while; file transfer speeds hover around 20MB/s), and PLEX remains nearly inoperable, especially when trying to stream larger files. I have attached logs if anyone could possibly help. I'm happy to provide any further information. Thank you. tower-diagnostics-20181126-1930.zip

Will do; in the meantime, is there anyway for me to remove the read only limitation until I can get a new drive this week? I was musing on replacing the whole box for something more robust -- so as a side note, if anyone knows of a decently priced out-of-the-box option I'm all ears. I built this box from scratch for unRaid years back, never thinking I'd want to expand past 5TB (so naive), but I don't have the time to do so these days. Cheers!

Here you go.... towertwo-diagnostics-20160207-1012.zip

A few days ago my third of three drives failed. I followed the usual steps and rebuilt the drive from parity and everything seemed fine, but I no longer have permission to write to the drive. I even tried running the 'New Permissions' script, even though this is entirely on v6.1.6. Nothing has changed on my system since the crash/rebuild, not even a Windows Update (to my knowledge). I'm running unRaid v6.1.6 Windows 7 Ultimate SP1

Oh, and I'll note that my first response to this was to run the "New Permissions" script, but no luck.

Had a recent power outage and full everything reboot; as far as I can tell, everything is working as should be except I can no longer copy/delete/write to my unRaid server. I get an aggravating "You need permission to perform this action" error that simply did not exist before, even though I'm logged in as the only login as I've always used for these activities, including just hours before I suddenly found I "need permission to perform this action." Thoughts?

Tried something different -- connected my unRaid box to an older Netgear Gigabit Switch that has the handy ability to see via the port lights if I'm connected at 10/100 or 1000. Lo! and Behold, My box is connecting -- at launch -- at only 100Mbps, despite all new cords and an brand new PCIe Gigabit LAN card. curiously, when the box crashes off the network, I can run the ethtool and get a reading of 1000Mbps from the box -- is it possible that unRaid "senses" gigabit speeds after being up for a while and then tries to run at that rate and that is causing it to crash off the network? Has anyone heard of this behavior before?

Just had an interesting thing happen twice -- my server fell offline; when I checked ethtool, the results are showing 1000Mb/s! So it appears my server box is ship-shape but...what? Is there something downstream that can't handle it in this case?

I'm stumped. Tried different ports, added all new cables, new Gigabit PCIe card, verified everything I have found to verify. Is it impossible that this is a software config issue? Are these problems 100% hardware?

Firstly, thank you everyone for your help lately -- making my experience better and better! I am stuck on trying to figure out why I cannot get gigabit speed from my server. Everything is up to par -- new CAT6 cables, Buffalo Airstation Gigabit router/bridge, etc; yet my ethtool and Info check won't read above "Network: eth0: 100Mb/s - Full Duplex." There are two LAN ports on my board, one 100Mb/s onboard and a PCIe 1000Mb/s, to which the server is connected to the router. Is it possible the config is 'seeing' 100Mb/s on the onboard (which I've disabled in the BIOS) somehow? Or am I missing something else I could tweak? Thanks!

Sorry for the confusion! Only Disk2 is red-balled; but on my Dashboard, I have a "Data is invalid" alert. I must have misinterpreted this as meaning Parity is invalid, but I'm now guessing it just means Disk2. Here's a screenshot...

Another thought -- if indeed the issue could possibly be related to the power problems we had, is there a way to ask the system to re-read that disk, i.e., re-integrate it into the array? And what would happen if the disk is truly fried somehow (though that seems so unlikely)?

Hmm, so if the swap-disable worked, would I recover only up to the day the 2nd drive went "red ball" on me, since Parity has been invalid since then?

Not sure if it is still a limitation, but the v6_b12 beta I believe does not support PLEX server, in case you need that functionality.

Aggravatingly, we had a power-outage midday a few days back while I was at work, so even my UPS died. I reckon that means my syslog is kaput. So rule of thumb is always to ensure 'green' drives first and parity is good, then swap up the parity drive for a bigger one, correct? Will parity remain invalid until I can clear the red dot?

Is it possible to use a USB Ethernet adapter instead of the onboard? My box is pretty great except for the 100Mbps ethernet port, so I was hoping to use a USB adapter to speed up my throughput. Alternately, if anyone knows how to overclock the ethernet port...

Hi there, I'd like to make sure I get this right: I have a four-disk array; Parity is 2TB, then a 2TB, 1TB, and 750GB. The 2TB -- which is my newest drive -- is now reading as faulty. I purchased a new drive that is 3TB. In which order should I upgrade, given that the new drive is larger than my Parity drive? Also, does anyone know a way to test for the source of the fault? The drive's self-test was fine, and it is a fairly new Seagate Baraccuda 7200.14 (and SMART test came back as PASSED). I am wondering if there is a painless way I can track down if it is possibly voltage, the SATA connector, etc. without having to acquire an engineering degree (though I'd love to). Cheers, Chris

Ah, you are correct -- my brand new 2nd drive has turned red. It is a new drive, passed all benchmark checks, etc. I switched to beta 4 because my last 2nd disk also went red, then turned out to be fine. I guess the problem could be with my other hardware -- cabling, etc -- but that doesn't explain why I am no longer allowed to access the server due to permissions.

I can't find the instructions that explain how to parity sync in 6.0 beta 4 -- I'm no longer given the option on the Home screen. Please advise/link.