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"; } }

I'm having trouble getting this container to pick up an IPv6 address. I have IPv6 configured in both the main network settings and the docker settings. I have the container setup to use br0 and use a fixed IPv4 address. However, when I open a console in the container and run 'ip -6 addr' it shows nothing. I'm on Unraid v6.6.6 with the default IPv6 settings. Does using a static IPv4 address cause issues with IPv6?

Ok, got it. If you want to use Fan Auto Control, which I really like because it uses the drive temps instead of CPU or system temp, then you may need the modprobe command. There doesn't seem to be a way to manually enter the driver there.

Are you using Fan Auto Control too? Or just System Temp? Were you able to get both working without using modprobe?

Glad to hear it worked! I'm usually the one asking the questions, so it's nice to be able to help. I think you'll need to add that command to your go file in order for the functionality to survive a reboot.

I was just trying to get my motherboard working (MSI X470 Gaming Pro Carbon) with the fan controller and seem to have figured it out. Here's what I did (being verbose in case it helps others troubleshoot their own motherboard in the future): Used sensors-detect to figure out that my board has a `VIA/Winbond/Nuvoton/Fintek' chip reported at ID 0xd352. Did a bunch of googling to find out that my board specifically has the Nuvoton NCT 6795D chip. More googling to find the supported devices: https://hwmon.wiki.kernel.org/device_support_status_n_o More googling to figure out that the nct6775 driver may also support the nct6795D. Tried 'modprobe nct6775 0xd352' (not sure if I was supposed to use force_id=0xd352, but it worked without it) and surprising, it worked and now the Fan Auto Control plugin shows my 6 nct6795 PWM controllers! So @Taddeusz maybe try 'modprobe nct6775 0xd423' (with or without force_id=) and see if that works for you. My only complaint now is that I'd like to be able to control more than one of my 6 PWM controllers. EDIT: Also worth pointing out that while detect doesn't work in the System Temp plugin, manually entering 'nct6775' as the driver and hitting save does. Enables me to see/select the temps and fans.

I have an issue with Fan Auto Control where I need to re-select the correct drives to exclude after every boot. It seems to just randomly select drives so I need to change it back to my 2 cache drives (SSD) to exclude. It does always select 2 drives, just not the correct ones. I assume this is a bug and just wanted to report it here.

Anything we should know about switching to the new version? It is as simple as: Uninstall the old plugin Install the new plugin Point the new plugin at the same destinations

@Squid Thanks for spending time on this even though it's not really an issue with your plugin!!

It's just a theory really, but I couldn't think of any other difference between a manual run of this backup script and the scheduled ones. I never had an issue with a manual run. This work around seems to be helping so far. Also: It's not really clear above, but I run mover every night and the backup script once per week. I wanted to make sure there was no overlap on the day they both run.

@SelfSD I've had this same issue. Not really a fix, but I have found that (so far) the problem is avoided by adjusting my schedules so that Mover runs at midnight and this backup runs at 4am. That seems to leave enough time for Mover to finish so there isn't a conflict. I wish there was a more concrete solution, but so far so good...