constellation

Yeah, that's the thing. That has always been set to No so I'm not sure why it even be enabled. Even after reformatting to XFS, I see in the logs that when it got mounted, the Recycle Bin was still enabled for it. I'm also still seeing the same issue on the VM. Will give the server a reboot and try again but things aren't looking good.

I'll reach out to the Recycle Bin dev as it should already be disabled for Unassigned Devices. I've also reformatted the drive to XFS for now to see if that stabilizes things. Thanks for the input, I'll see if this helps.

Oops, sorry. Yes, here it is. I'm also reformatting the drive to XFS in the meantime since I'm getting a bunch of NTFS errors for some reason. basementnas-diagnostics-20200205-1925.zip

Anyone have this issue before? I have a drive set as an unassigned device. I map a folder in it as a network drive in Windows 10. I use Steam and point to the mapped network drive as a secondary Steam library. I try to install a game, it looks to download fine. I try to install a second game at the same time and when it's preallocating the game files for the second game, disk activity for the first game's download goes down to less than 1 megabyte per second. It eventually stalls out and Steam crashes. The Main tab on Unraid now doesn't load the Unassigned Devices portion. I also can no longer access my array, it seems that UD has crashed all my network shares altogether. I try to stop the array, but it just stays there and the web interface times out. I have no choice but to manually shut down and now have to do a parity check. Can UD not handle setting up an unassigned drive as network share for a Steam library with all the disk i/o it brings?

Can you run another instance of this docker for another duckdns account?

Why the need to stop the array during install? Will just flipping VM's to disabled or enabled accomplish the same thing, or is there something more being done behind the scenes?

Step 11.b is very confusing to me. Why in the example are you passing 00:14.0? In the previous steps, it seems like 00:1a.0 is the one you should be passing. I must be missing something super obvious.

Stuck in the exact same situation. Hopefully someone out there has advice and a solution.

Thanks for that. I added tzdata to the docker per the command. However, I think the timezone change caused issues in displaying videos that have already been recorded. Not sure if anyone knows how to clear all recorded videos in Shinobi? EDIT: Actually it seems like only the motion events are saved to the DB. I think for videos it just tries to detect what videos are available based on the filenames. I just started with a clean slate and deleted all videos for now. Moving forward all files created have the correct timestamp in the file name at least.

Triggering motion detection via FTP isn't working as well. I'm getting the exact same error as this reddit user: The Shinobi dev apparently fixed it in a dev branch, but obviously this being a docker we don't have an easy way of applying it. @SpaceInvaderOne are you able to help?

Same problem here. The GUI has the correct time, but the Calendar view and the Power Video view shows UTC which obviously isn't ideal.Same problem here. The GUI has the correct time, but the Calendar view and the Power Video view shows UTC which obviously isn't ideal.