shooga

Thanks for taking a look. That issue sounds vaguely familiar, so I may have already taken care of it. I will take a look when it's done with the parity check to make sure. It seems strange that this would become an issue after having stability for years, but I guess you never know. Is it possible that logging via the network caused messages to be missed? Like, maybe it's a network issue causing the problem, so the messages aren't getting logged?

I have been getting somewhat infrequent (it's happened 3 times in 2 months) crashes since upgrading to 6.12. I'm now on 6.12.2. Server was completely stable before this upgrade. Upgrading to 6.12.3 seems like a simple thing to try, but I figured I'd check in here first. It's a complete crash with no access to any containers, VMs, GUI, network storage, or terminal. Attached is a sanitized log captured via a separate syslog server. I don't see anything useful immediately before the most recent crash (this is the first crash after I started capturing the log). Any help would be greatly appreciated!! unraid.log

Ok, thanks @itimpi. Probably no point in using an nvme drive unless I can use two then.

Scrutiny tells me that it's time to replace the 7 & 10-year old SSDs in my cache pool. Currently, I have one drive in an nvme slot and one that is a SATA drive. How are the two drives used? Is one drive treated as the primary and one as a secondary? Does it use both drives equally? I'm wondering if there's a performance gain from having only one drive as nvme, or if the SATA drive slows down the whole pool. If that's the case I may just get an nvme to SATA controller, use two SATA drives, and expand my capacity a bit.

Thanks for letting me know about this @Kilrah. I will probably move to your container as the migration last time wasn't as bad as I expected.

Thanks again, @CorneliousJD! This has renewed my faith/interest in using Nextcloud. I added the preview providers via config.php. I just copied your block and tried it with the video previews still in to see what would happen. Turns out .mp4 and .mov previews work without installing ffmpeg. I was surprised, but I'm not complaining... Edit: I take back what I said. I think I misunderstood what they meant by previews. The videos will play inside Nextcloud when I click them, but there's no thumbnail. Maybe that's what the preview is? Would you mind sharing your script to install ffmpeg so I can give it a try? In this documentation they recommend using their Imaginary container to speed up previews, but the performance is quite fast for me right now so I don't see the point.

I know I'm reviving an old thread, but I'm following the example of @CorneliousJD and have a few questions. Hopefully he sees this... When I try to set the `APACHE_DISABLE_REWRITE_IP` container variable it fails to start and I get an error in the logs `Could not remove /etc/apache2/conf-enabled/remoteip.conf: Permission denied`. If I remove that variable it starts and seems to work fine. I have `trusted_proxies` setup in config.php and everything seems to work. Do I need to fix this? What exactly does this variable do? I see in your config.php that you are using a preview provider. I see mention of using Imaginary in the docs for tuning, but you don't give a url for the imaginary instance. Is Imaginary built into this container? Or how does that work? The good news is that so far it's running MUCH faster and seems like everything is working. Thanks in advance!

Answering my own question here in case it can help someone in the future: I spent a bit more time with the documentation (and google) and found the backups folder in appdata/audiobookshelf/metadata/backups. No need to map it beyond that as the my appdata is on a cache pool and I backup the appdata folder regularly.

I've just recently found this and it's awesome. I'm excited to have an audiobook manager like this. Thanks for your work on this @advplyr! Quick question: Where are the library backups stored and can that be mapped to a share? I tried to find them but wasn't able to (it looked like they'd be at /backups/). It also didn't seem to work to simply add another path to the container configuration. I'm probably missing something or just doing it wrong... TIA!

Thanks for taking a look. I have a precleared cold spare. Do you think it's time to replace this drive?

I received warnings that a drive has errors. The drive is reporting 64 errors, but when I run the extended SMART self-test it passes. What would this mean and what should I do next? My server has not been opened up so a loose cable seems unlikely. I recently had errors in a parity check and did a second, correcting check (maybe that was a mistake). Maybe this drive is failing and slowly causing more errors? Diagnostics and smart report attached. bunker-diagnostics-20211218-0900.zip WDC_WD60EFRX-68L0BN1_WD-WX11D76EP20F-20211218-0856.txt

Thanks for the response. I'm getting a ton of: May 30 09:36:21 Bunker move: move: file <filename> May 30 09:36:21 Bunker move: move_object: <filename> File exists And it's actually happening for other shares that I wasn't trying to relocate to the other cache. Strangely, when I look at the disks directly (on the array) I don't see all of the files that it is referring to. I see other threads where the suggestion is to delete the files on the array and trigger mover again, but in this case I don't see the files to delete them. In most cases, I don't see the conflict. Another note (probably just an unrelated bug): the GUI displays the wrong cache name (I changed the name of the primary cache) on the Shares tab.

I'm trying to do basically the same thing (move a share from one cache pool to another) so I thought I'd try this thread rather than starting a new one. I have tried the suggestions above: Change share from 'prefer cache' to 'yes' Disable docker and VMs in settings Trigger mover Change share back to 'prefer cache' with the new cache Trigger mover Re-enable docker and VMs However, my share is left unchanged with all of the files remaining on the old cache - they never even get moved to the array. I'm not aware of anything holding the files open. What could be going wrong? Thanks!

Thanks @bigmakfor the response. I had added :443 while trying different things I found in my research - it didn't work and I've removed it now. Turns out I didn't need to add a location for esphome specifically (/a0d7b954_esphome), but needed to add the /api/hassio_ingress location. Saw that in your config and thought it was worth a try. That fixed it! Now it works for esphome and vscode. Thanks again! Just to be clear for anyone else looking for help, this is the section that I needed to add. Maybe it's in the latest config sample with the container, but it wasn't in mine. location /api/hassio_ingress { resolver 127.0.0.11 valid=30s; set $upstream_app 192.168.1.205; set $upstream_port 8123; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $host; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; }

I'm using this container successfully as a proxy for several other containers and also for a VM running Home Assistant. I modified the included config so that it would work with the VM and it seems fine except for websockets in some of the hassio add-ons. Websockets work fine via the local IP address, but not via the proxy. Is there a reason that I can't simply add the necessary websocket config lines to the / location? That seems to kill the whole thing. As it is, I have tried to add another location for the base url of the add-on that I'm trying to enable websockets for (esphome here, but I've also tried vscode). It's not working and I believe it's most likely because I'm not configuring the proxy correctly. Proxy config is below. Any help would be greatly appreciated! server { listen 443 ssl; listen [::]:443 ssl; server_name homeassistant.*; include /config/nginx/ssl.conf; client_max_body_size 0; location / { include /config/nginx/proxy.conf; resolver 127.0.0.11 valid=30s; set $upstream_app 192.168.1.205; set $upstream_port 8123; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; } location /api/websocket { resolver 127.0.0.11 valid=30s; set $upstream_app 192.168.1.205; set $upstream_port 8123; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $host; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } location /a0d7b954_esphome/ { resolver 127.0.0.11 valid=30s; set $upstream_app 192.168.1.205; set $upstream_port 8123; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $host:443; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } }