-
Nextcloud AIO causes HDD spin-ups even when data is on NVMe cache (FUSE /mnt/user metadata issue)
Hi all, I'm running nextcloud-aio-mastercontainer on Unraid and trying to optimize for NVMe cache usage while keeping bulk data on HDDs. Setup: - Nextcloud AIO Docker - Data directory: /mnt/user/nextcloud - Share configured with cache + array Problem: Even when data is physically located on the NVMe cache pool, my HDDs still spin up frequently during normal Nextcloud usage. This happens during: - Web UI browsing - File listing - Preview access - general metadata operations What I observed: Even without accessing HDD-resident files directly, disks still wake up. My assumption is that Unraid's FUSE layer /mnt/user) is resolving file metadata across all disks, not strictly using cache-only paths. - HDDs do not stay spun down - NVMe cache benefits are partially negated - noticeable increase in disk activity and power usage Is there any recommended way in Unraid to: - fully isolate Nextcloud data to cache for metadata + IO - avoid /mnt/user FUSE overhead for this workload - or split hot metadata (previews/appdata) and cold user data safely? I'm especially interested in setups that still work cleanly with nextcloud-aio-mastercontainer Thanks in advance!
-
[SUPPORT] TEMPLATE MASTERWISHX - FileBrowser Quantum
Thank you very much, that's exactly what I was looking for! I appreciate your work and effort for your first stable release! Some additions would be great: if there would be a privilged user who can do everything, but not taking the admin rights from the real admin rules for passwords to make it safer if this service is public Other than that, it's the best tool I have seen so far to share data with friends!
-
[Support] Octoprint docker template - Spants
Hello, I got a Snapmaker Artisan as 3D-Printer and was able to connect it with this container. It works great (I use it as a connection to home assistant, thanks for that!), but I have one issue I could not resolve after weeks: The Snapmaker 3D-Printer is just turned off by the power supply. There is no G-Code Command to turn it off and therefore octoprint does not recognize that the device turned off and sends the following log message: "device reports readiness to read but returned no data (device disconnected or multiple access on port?)". Then the container turns off. -> Have a look at the attached logs. Is there a way to keep the container up and running eventhough there is no command sent by the printer via serialport? My workaround would be to check via a script running on a cronjob if the container turned off and start it again, but I hope there is a more elegant solution.
Felix2M
Members
-
Joined
-
Last visited