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?