Jump to content

nphil

Members
  • Content Count

    5
  • Joined

  • Last visited

Community Reputation

4 Neutral

About nphil

  • Rank
    Newbie
  1. Yay, finally! If anyone else runs HomeAssistant and unRAID, this is basically a one-way MQTT bridge from unRAID to HA. You can control containers, VMs, USB hotplugging, etc. Please help with testing and feedback!
  2. I can attest to this - I forgot that I turned on DirectIO somewhere along the way.. I turned it off, restarted my array and all my docker containers now start properly even with the path set to /mnt/user/appdata. Turn it back on - none of my containers start - DB errors everywhere. Not saying this is necessarily related to db corruption over time issues that users are having - but in my case this is definitely the culprit. Saw this thread from a while ago with people having similar issues:
  3. Thanks for looking into this. Unfortunately, this didn't seem to make any difference. I verified the extra config file and started/stopped the array twice to double check. Multiple docker containers (plex, sonarr, radarr, nginxproxy, nzbhydra, bitwarden etc.) refuse to start unless I switch back to /mnt/cache/appdata. They all give some variation of "database corrupted" error. What I don't understand is why I didn't have any issues with 6.7.0 (where these first user reports started popping up), and only after I upgraded to 6.7.1. Let me know if there are some other steps I can take.
  4. Some background: I was running 6.7.0 and eveyrthing was fine. Upgraded to 6.7.1 - any container that had a .db file stored in the cache drive refused to start. Changed path of the docker containers from /mnt/user/appdata to /mnt/cache/appdata and everything has been running smoothly for almost 3 days now. Just for a test, I upgraded to 6.7.2 and installed a bitwarden container with everything default and the db mapped to /mnt/user/appdata. I keep getting DB errors right away and the container refuses to start. Switching the path to /mnt/cache/appdata resolves the issue immediately. So in my case, it's not a matter of DB corruption over time ( at least not that I've noticed yet) - docker containers that have db files with the appdata path set as /mnt/user/appdata just refuse to start unless changed to /mnt/cache/appdata. beastnas-diagnostics-20190626-2148.zip
  5. Upgraded to 6.7.1 - got DB corruption issues with a bunch of containers: Plex, Unifi, Sonarr, Radarr, etc. anything with a db file inside appdata. Everything was fine on 6.7.0 Downgraded to 6.7.0 - same issue persists. On docker settings, manually switched the location of appdata from /mnt/user/appdata to /mnt/cache/appdata and suddenly everything works fine. additional details about my cache drives: 2x NVME drives formatted BTRFS running in single mode to maximize available space.