Jump to content

DaleWilliams

Members
  • Content Count

    987
  • Joined

  • Last visited

Community Reputation

0 Neutral

About DaleWilliams

  • Rank
    Advanced Member

Converted

  • Gender
    Undisclosed
  • Personal Text
    Noob...and always will be

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. http://lime-technology.com/forum/index.php?topic=9880.0 Post your syslog.
  2. Look in SHARES tab. Find the APPS share definition. Setting should be 'cache only'. If you don't have a defined APPS share, create one and set it as Cache Only.
  3. Turn off AFP if you've set it ON. Unless you're running TimeMachine, you probably don't need it.
  4. Thanks for the update, jonp. [me=DaleWilliams]applauds everyone involved! [/me]
  5. http://lime-technology.com/wiki/index.php?title=The_Analysis_of_Drive_Issues#Drive_interface_issue_.231 Your syslog shows both sdr and sdq having issues....and at first glance appear to be physical. Try the link above for details, but in summary, SATA cable may be bad/loose. Also could be a power supply problem, so check that all connections are solid. Perhaps those two drives share a common controller, are in the same drive cage, or share a SAS cable?
  6. There are settings in the PLEX GUI interface (not the PLEX VIEWER app, but at port #32400), look for the ADVANCED tab, and you should be able to limit the frequency with which PLEX checks your disks for new media in your library. You can turn them off and make the updates manual. I just do them once per day.
  7. What's on it? Did you install something like a torrent engine, or PLEX?
  8. check the web page of the card manufacturer (Syba and maybe Marvell) for a firmware update that supports drives > 2.2 TB.
  9. syslog Line #1684 = Jun 23 15:35:04 Server kernel: ata4.00: exception Emask 0x10 SAct 0x0 SErr 0x4010000 action 0xe frozen http://lime-technology.com/wiki/index.php?title=The_Analysis_of_Drive_Issues#Drive_interface_issue_.233 This is transmission error. Most common causes are power related or unreliable connection especially if backplanes are involved. Is the problem still reproducible? If so, can you please try to move it to different power connector and SATA port and see what changes? ATA4 is this disk, "ST3000DM001-1CH166"
  10. Without a syslog, I'd suspect simple file directory corruption because of the power outage. Shutdown the array, put the flash in a PC (Mac) and run chkdsk (Disk Utility) on it. If that doesn't fix the problem, then check back in and post your syslog. http://lime-technology.com/wiki/index.php/Troubleshooting#Capturing_your_syslog (If you use a web Gui add on for unRAID ( like Dynamix or unMENU) the syslog may be on one of the web interface pages, too. Be sure to post the ENTIRE log, not just the little summary of the last 20 lines.)
  11. BOX.com There's no Linux Sync native cabability but they have webdav and some folks use copy.com http://seb.so/50gb-of-cloud-space-with-box-automatically-syncd-on-linux-with-webdav/#box_mountwebdav https://support.box.com/hc/communities/public/questions/200285268-Box-Sync-for-Linux-anyone-
  12. You have several disks showing errors. ata#15,16,17. Are they all on an add-in SATA card? There are CRC errors which can be bad SATA cables. The other possibilities (from the wiki at: http://lime-technology.com/wiki/index.php?title=The_Analysis_of_Drive_Issues ) are: However, if a better SATA cable does not solve the issue, then it is probably a power problem (loose power cable or backplane connection, poor connectors, poor power splitter, overloaded power supply, too many drives on power rail, bad power supply, etc). Because you have THREE disks with errors, I'm wondering if its an add-in card?
  13. sorry, I bobbled the quote of the last line from the Wiki. It says, "If you get an error that says reiserfs_open: the reiserfs superblock cannot be found on /dev/sdX. Failed to open the filesystem. it usually indicates you attempted to run the file system check on the wrong device name. For almost all repairs, you would use /dev/md1, /dev/md2, /dev/md3, /dev/md4, etc. If operating on the cache drive that is not protected by parity you would use /dev/sdX1 (note the trailing "1" indicating the first partition on the cache drive) " So (again from the Wiki) your command to check the cache drive would be: reiserfsck --check /dev/sdh1 Assuming that the cached drive is 'h'. (That verification that cache=h was what is cut off at the beginning of the log.) A complete log may require that you Telnet into the box, and copy and paste it out by hand. If you're picking it up from a web gui, it may be truncating it. There should be a 1000 lines or so of 'setup', where unRAID is busy finding the drives, assigning them drive letters, loading your plugins, etc.
  14. I'm not as good at Syslog reading as most on the forums. It looks like you restarted the log, thus cutting off the startup sequence. The startup is where drive assignments show up...so drive 'sdh' is clearly in trouble...but I can't tell if that's cache or not. Later on, 'cache' has some open files and kicks out some errors, but they could be totally separate. What I would do is run SMART on all your drives, and post results as well as full syslog. Include your VERSION and SYSTEM LOG for support issues If you're sure that its the cache drive and SMART is clean, then run "Reiserfsck --check" on it to see if you can clean up the directory. Cache is a bit of a special case, so read the Wiki and mind the last sentence on the page: http://lime-technology.com/wiki/index.php?title=Check_Disk_Filesystems "If operating on the cache drive that is not protected by parity you would use /dev/sdX1 (note the trailing "1" indicating the first partition on the cache drive)"
  15. Oh! ....huh! I've no idea. Someone more in tune with unRAID innards will have to weigh in.