• Content count

  • Joined

  • Last visited

  • Days Won


John_M last won the day on May 28

John_M had the most liked content!

Community Reputation

99 Good

About John_M

  • Rank
    Away for much longer than I expected


  • Gender
  • Location

Recent Profile Visitors

726 profile views
  1. John_M

    Network Drive Unstable

    First thing I'd do is try it with a cabled connection.
  2. John_M

    Network Drive Unstable

    Are you using a cabled network connection or wireless?
  3. I had a problem with a motherboard I'm using for another project - not unRAID. I needed to boot from a FreeDOS USB stick in order to update the BIOS but couldn't make it boot until I disabled the Compatibility Support Module (CSM). The newer BIOS fixed the problem.
  4. John_M

    Oh boy, here we go, CRC errors

    If it happens to one disk it's usually a bad cable. When it happens to eight disks simultaneously I'd suspect that "loose controller card". If it proves not to be that the next thing I'd suspect is the power supply or the power distribution to the disks.
  5. The wrong csrf_token error is caused by you having a stale browser window open from before your last reboot. Check your phone/tablet/other PC. Your Time Machine problems are caused by a corrupt CNID database. See here:
  6. John_M

    Any news on 6.6?

    Sounds like you need a second server.
  7. I do have a MacBook Pro that runs High Sierra and I use SMB whenever I mount an unRAID share but I don't use unRAID as a Time Machine destination for that computer. I just use a USB-connected external hard disk.
  8. John_M

    Network card has same id as onboard

    Try either a different brand of card or a different Intel model. The 8086 is Intel's vendor ID and the 1521 means an I350-based NIC. See here.
  9. John_M

    Unmountable : No file system

    You said that you moved your server yesterday. It might be a coincidence but it's possible you disturbed something. Could you have removed the power before it had finished shutting down?
  10. It's caused by corruption of the Netatalk database, which has proven to be quite fragile. There's a separate database for each AFP-exported share and it's kept in the .AppleDB folder in the root of the share. So for a share called ShareName, the database folder is /mnt/user/ShareName/.AppleDB. There have been discussions about this before here, here and here. The trouble is that AFP is not used much these days and support for it might well be removed from unRAID in the not too distant future. I'll be disappointed when that happens because I have a number of old Macs that can't be upgraded to newer than OS X Lion and whose SMB implementation is clunky. In the meantime here's what you can do to improve your own experience. The quick fix is to shut down your Mac, then from the unRAID command line delete the .AppleDB folders from the root of each share. rm -rf /mnt/user/ShareName/.AppleDB Then restart the Netatalk service (rebooting your unRAID server will do that). Then restart your Mac and mount the share. This initial mount will take a while as the database is rebuilt. A longer term fix is to do what I did and move the location of the database away from the root of the share. A good location would be onto your cache pool. Unmount all AFP-mounted shares first. I made a new folder within the system folder (/mnt/cache/system/AppleDB) and pointed Netatalk to it - in the unRAID GUI go to the Shares page and choose one of your exported shares. Scroll down to AFP Security Settings and edit Volume dbpath to be the name of the new location (in my case, /mnt/cache/system/AppleDB) and click Apply. Repeat for your other AFP exported shares, giving the same location. When you next AFP mount your shares the /mnt/user/ShareName/.AppleDB folder will automatically be relocated to /mnt/cache/system/AppleDB/ShareName/.AppleDB where it is much more responsive and much less prone to corruption.
  11. John_M

    Unmountable : No file system

    Since the file system remains unmountable you can't replay the log so the next step is to go back to Maintenance mode and run xfs_repair with the -L option. The wording of the message suggests this is a bad place to be; in practice the only files likely to be affected are any that were being written at the time the corruption happened.
  12. John_M

    FQDN doesn't work/respond

    Is "sun" the name of your unRAID server? What do you mean by "nothing happens"? Does ping fail because the name cannot be resolved or because there's no response from the host? Can you ping your other (fully working) Windows machine by name successfully? Does this mean that "sun" is in fact the name of your messed up Windows computer? If so, from where were you trying to ping it? I'm more than a little confused by your question because it doesn't seem to align with the thread title - "sun" is not an FQDN.
  13. John_M

    Slow turbo write speeds

    If you copy or move files from one disk to another with turbo write enabled twice as many blocks have to be read from the source disk as the other disks: first the source file has to be read and then, after a seek operation, the same disk is read once again for the parity calculation. The destination disk is written once and so is parity. All the remaining disks are read once. So the source disk is working harder than the others.
  14. John_M

    unRAID Random Crashes (v 6.5.3)

    @tayshserve Did you update the BIOS? That was the first thing to do before trying the boot option. As I said, ASRock's support for Raven Ridge has been poor and all but the most recent (as in, released in the past few days) BIOSes have been broken. I have an ASRock Fatal1ty B350 mITX board with an R5 2400G (not using it for unRAID) and I've experienced this and it's confirmed on the ASRock support site. Anything earlier than August 2018 is bad if you're using a 2000-series processor. Edit: I see that you did update the BIOS. I missed that earlier. @PSYCHOPATHiO Even "downclocking" your 3200 MHz-capable memory to 3000 MHz is actually still overclocking your processor's memory management unit. 1000-series Ryzens are designed to run their MMUs at maximum 2666 MHz and 2000-series at 2933 MHz (and, depending on bus loading, could be significantly lower - I notice you have four DIMMs but I don't know their part numbers so can't tell exactly how many SDRAM chips are loading the bus) so anything faster is technically an overclock and might need an increase in SoC voltage for stability. If you run it at 2666 instead, your uptime should be better. There are good reasons why some DIMMs are not on the QVL!

Copyright © 2005-2018 Lime Technology, Inc.
unRAID® is a registered trademark of Lime Technology, Inc.