JamieK

Members
  • Posts

    16
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

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

JamieK's Achievements

Noob

Noob (1/14)

2

Reputation

  1. FWIW I'm following #2 and am not seeing corruption issues.
  2. Fair enough! You're right that my docker.img is on disk1 (though I'm not quite sure why that's the case). I'll stop my containers and move it. Thanks for your advice!
  3. I forgot to un-assign a drive before swapping it out for a new one, and to clear up my mess used 'Tools > New Config' to reset my array with a valid Parity drive. I'm not sure this was necessarily the right way to do this (it might have been overly dramatic)! However, I was surprised that this also cleared out my Docker config and I had to set up my containers again. Could you consider adding some warning text on the 'Tools > New Config' page to say that this will happen?
  4. Thanks Squid, that seems to have done it – I'd tried re-saving but never actively changing it.
  5. Whoops! Sorry, I missed attaching them. Done. tower-diagnostics-20190809-1219.zip
  6. Hi everyone, I have Scheduler configured to run the Parity Check at 2am every Sunday, however it seems to run at 2am every night. Any hints as to why this might be? Or should I file a bug report? I'm running 6.7.2. Thanks!
  7. One week on, I'm seeing no issues using the disk1/cache-preferred setup I described above. Running an integrity check on both Sonarr and Plex's databases returns no errors; and everything seems stable.
  8. So far so good... There's also a noticeable speed benefit (though that's to be expected I guess). Note that i'm effectively running my databases on the cache drive only, with fallback to disk1 if they get too full. This does mean you lose parity on them, though.
  9. I've been debugging this solo, but came across this thread and wanted to share my experiences in case they might offer some pointers. Unraid has been bulletproof for me until now – I'd love to help you guys with this if I can! I've been having regular corruption over the past week or two. It first occurred on 6.7.0, and has definitely become worse on 6.7.2. A couple of days back I created two new shares – Plex AppData and Sonarr AppData, configured both to prefer the Cache (but exist on disk1 only), pointed both Plex and Sonarr there via /mnt/user/[app-specific share]/ and that seems to have potentially fixed the issue – the corruption was nightly before. I'll keep watching. The sqlite3 .dump and re-ingest trick has never worked for me when the databases have corrupted. I also noticed that when Sonarr's db hosed itself, Plex's performance for the TV library became abysmally slow – often timing out. Music and Movies were unaffected, and still loaded. As soon as I stopped the Sonarr container, Plex performance recovered. I've attached my diagnostics in case it's useful. tower-diagnostics-20190801-1307.zip
  10. The new warning on the Main tab in 6.6.4 that the Flash drive is publicly shared via SMB appears when Samba is disabled at the system level. The settings to change this on the drive only appear where you enable Samba. This led to a lot of confusion as I tried to work out why I couldn't see the settings for the Drive as described by others. Expected behaviour: – Warning only appears when the Drive is actually shared, or – Allow users to change Samba settings for drives even where the service is stopped
  11. I mean I thought it might be, but I didn't like to point fingers 😂 would you like a BR?
  12. Got it – I had SMB fully disabled (I just don't use it) so the setting didn't show. It seems a little weird that the warning would be shown where the drive isn't actually exposed...
  13. I'm now seeing this, but I'm not sure how to correct it. Clicking through to 'Flash' doesn't show me any security options. Any hints gratefully appreciated!
  14. Standard 'I've searched but can't find anything' – forgive me if this is answered elsewhere! My unRAID array won't shut down correctly – it gets stuck in a loop of 'Retry unmounting disk share(s)'. Following other topics, I installed the Open Files plugin and can see that Docker's metadata.db (/var/lib/docker/volumes/metadata.db) may block shutdown. A custom script I run – a shoutcast server – is also listed but doesn't seem to block shutdown. Can anyone suggest how I might be able to resolve this? I end up forcing shutdown each time I need to restart unRAID. Many thanks.