Froberg

Seems like it had another crash during the night.. fortytwo-diagnostics-20220609-1637.zip

I'm having it too with standard SSD's.. find any cause? Jun 8 03:18:34 FortyTwo kernel: BTRFS error (device sdb1): block=455832535040 write time tree block corruption detected Jun 8 03:18:34 FortyTwo kernel: BTRFS: error (device sdb1) in btrfs_commit_transaction:2438: errno=-5 IO failure (Error while writing out transaction) Jun 8 03:18:34 FortyTwo kernel: BTRFS info (device sdb1): forced readonly Jun 8 03:18:34 FortyTwo kernel: BTRFS warning (device sdb1): Skipping commit of aborted transaction. Jun 8 03:18:34 FortyTwo kernel: BTRFS: error (device sdb1) in cleanup_transaction:2011: errno=-5 IO failure Jun 8 03:18:36 FortyTwo kernel: blk_update_request: I/O error, dev loop2, sector 29152 op 0x1:(WRITE) flags 0x100000 phys_seg 1 prio class 0 Jun 8 03:18:36 FortyTwo kernel: BTRFS error (device loop2): bdev /dev/loop2 errs: wr 1, rd 0, flush 0, corrupt 0, gen 0 Jun 8 03:18:36 FortyTwo kernel: blk_update_request: I/O error, dev loop2, sector 458944 op 0x1:(WRITE) flags 0x1800 phys_seg 1 prio class 0 Jun 8 03:18:36 FortyTwo kernel: BTRFS error (device loop2): bdev /dev/loop2 errs: wr 2, rd 0, flush 0, corrupt 0, gen 0 Jun 8 03:18:36 FortyTwo kernel: blk_update_request: I/O error, dev loop2, sector 983232 op 0x1:(WRITE) flags 0x1800 phys_seg 1 prio class 0 Jun 8 03:18:36 FortyTwo kernel: BTRFS error (device loop2): bdev /dev/loop2 errs: wr 3, rd 0, flush 0, corrupt 0, gen 0 Jun 8 03:18:36 FortyTwo kernel: blk_update_request: I/O error, dev loop2, sector 459392 op 0x1:(WRITE) flags 0x1800 phys_seg 2 prio class 0 Jun 8 03:18:36 FortyTwo kernel: BTRFS error (device loop2): bdev /dev/loop2 errs: wr 4, rd 0, flush 0, corrupt 0, gen 0 Jun 8 03:18:36 FortyTwo kernel: blk_update_request: I/O error, dev loop2, sector 983680 op 0x1:(WRITE) flags 0x1800 phys_seg 2 prio class 0 Jun 8 03:18:36 FortyTwo kernel: BTRFS error (device loop2): bdev /dev/loop2 errs: wr 5, rd 0, flush 0, corrupt 0, gen 0 Jun 8 03:18:36 FortyTwo kernel: blk_update_request: I/O error, dev loop2, sector 460448 op 0x1:(WRITE) flags 0x1800 phys_seg 8 prio class 0 Jun 8 03:18:36 FortyTwo kernel: BTRFS error (device loop2): bdev /dev/loop2 errs: wr 6, rd 0, flush 0, corrupt 0, gen 0 Jun 8 03:18:36 FortyTwo kernel: BTRFS error (device loop2): bdev /dev/loop2 errs: wr 7, rd 0, flush 0, corrupt 0, gen 0 Jun 8 03:18:36 FortyTwo kernel: blk_update_request: I/O error, dev loop2, sector 984736 op 0x1:(WRITE) flags 0x1800 phys_seg 8 prio class 0 Jun 8 03:18:36 FortyTwo kernel: BTRFS error (device loop2): bdev /dev/loop2 errs: wr 8, rd 0, flush 0, corrupt 0, gen 0 Jun 8 03:18:36 FortyTwo kernel: BTRFS error (device loop2): bdev /dev/loop2 errs: wr 9, rd 0, flush 0, corrupt 0, gen 0 Jun 8 03:18:36 FortyTwo kernel: BTRFS: error (device loop2) in free_log_tree:3451: errno=-5 IO failure Jun 8 03:18:36 FortyTwo kernel: BTRFS info (device loop2): forced readonly Jun 8 03:18:36 FortyTwo kernel: BTRFS warning (device loop2): Skipping commit of aborted transaction. Jun 8 03:18:36 FortyTwo kernel: BTRFS: error (device loop2) in cleanup_transaction:2011: errno=-5 IO failure Jun 8 03:18:36 FortyTwo kernel: blk_update_request: I/O error, dev loop2, sector 32928 op 0x1:(WRITE) flags 0x800 phys_seg 2 prio class 0 Jun 8 03:18:36 FortyTwo kernel: BTRFS error (device loop2): bdev /dev/loop2 errs: wr 10, rd 0, flush 0, corrupt 0, gen 0 Jun 8 03:28:38 FortyTwo root: Restoring original turbo write mode Jun 8 03:28:38 FortyTwo kernel: mdcmd (129): set md_write_method auto Jun 8 03:28:38 FortyTwo kernel: Jun 8 03:44:08 FortyTwo kernel: blk_update_request: I/O error, dev loop2, sector 29152 op 0x1:(WRITE) flags 0x100000 phys_seg 1 prio class 0 Jun 8 03:44:08 FortyTwo kernel: BTRFS error (device loop2): bdev /dev/loop2 errs: wr 11, rd 0, flush 0, corrupt 0, gen 0 BTFRS has been the single most unstable thing with my UnRAID experience thus far..

Yup.. (It's being updated regularly.) Actually your post reminded me that linuxserver seems to have abandoned direct support of their UnRaid container offerings.. so I switched to binhex/arch-medusa instead just now.

I fail to see how it could be an ABS container issue, when it's working flawlessly on my end.

Noticed a lot of people asking about nginx proxy manager, here's my working setup: Hope it helps someone.

Eh my car is fairly random. It's a SKODA with the integrated option. It works fairly weirdly, haven't been able to resolve it. But basically: * Enter car and turn ignition * Mount phone and start playing audio * Go in to bluetooth media and press play (being able to see the artist but no audio) * This pauses playback on the device, press play on device and audio comes finally, but you can no longer see the artist information. This works for all apps I've tried.. but this software won't trigger the audio at all. Workaround is just starting audio from something else - and clearly it may just be my funky car stereo system at fault.. just figured I'd mention it regardless.

After having used this for a few months now, well, since you came out with it.. I cannot recommend this enough. This is flippin' awesome. Beats Plex with a large metal rod mercilessly. One oddity, which I'm sure can't be replicated. I use this exclusively in my car while commuting and I found something interesting. I am unable to get audio through my car speakers, until I start any other app - like PlexAmp - then pause that, which will allow me to hear the audio from Audiobookshelf. It's weird, and probably unique, but figured I'd mention it. It's like it can't initiate the audio signal on its own or something. Can replicate it every time I reboot the phone without fail.

Resetting the library fixed it. It kept trying to find files in folders I had deleted. It decided to remove the cover art for almost the entire library. Some it downloaded instead. But it seemed to suddenly decide to ignore the embedded covers, despite them working previously. If I delete an audiobook folder, will I then need to manually remove it from ABS too?

Err.. I may be missing something obvious here. Once I got the system up and running, I was made aware of some naming issues, missing serialization in my folders and some outright flaws in my files. So after renaming, reordering and general fixer-uppery I did I a rescan of the library. Now most of the embedded artwork has decided to disappear, and the "download artwork if missing" option didn't resolve it, either. What's worse is that it remembers the now-deleted directories where files used to be stored, incorrectly. How do I force it to let go of now-deleted stuff?

So I saw on your github that you're not accepting donations as yet, so I'll hold off on that for a while. Just got this up and running an hour ago, already I'm loving the library layout and the ease of use of it all. Miles and miles better than running it through my plex library. Much love to you. I can't wait to follow this application and see where it goes. I'm using the Android app as well, everything seems to just work. (Well, as soon as I ticked the right options in NPM ) Kudos man, this is great stuff.

You're on the linuxserver one, then?

Works fine without, tried that first, but I figured it should be there since it's explicitly mentioned in the OP?

Renamed to lower-case - postargs: docker exec -u 0 nxtcloud /bin/sh -c 'echo "umask 000" >> /etc/apache2/envvars' No joy, container won't load. log says: /entrypoint.sh: 194: exec: docker: not found

yeah it's the post-args, tried removing some stuff and it won't behave. If I remove all the post-args the container launches. I'll try and rename it lower case. Cheers.

Trying to use this to replace a b0rked LinuxServer version, and this was recommended to me. I already have a nextcloud, currently stopped, but I'm not deleting it yet, so I wanted to add yours as "NXTCloud" and changed the folder mappings appropriately, and added the variables and parameters you mentioned, even added a port number for bridge mode. It doesn't want to launch however. Removing container: NXTCloud Successfully removed container 'NXTCloud' Command:root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker create --name='NXTCloud' --net='bridge' -e TZ="Europe/Paris" -e HOST_OS="Unraid" -p '8666:80/tcp' -v '/mnt/user/appdata/nxtcloud/':'/var/www/html':'rw' -v '/mnt/user/appdata/nxtcloud/apps':'/var/www/html/custom_apps':'rw' -v '/mnt/user/appdata/nxtcloud/config':'/var/www/html/config':'rw' -v '/mnt/user/appdata/nxtcloud/data':'/var/www/html/data':'rw' -v '/mnt/user/Share/':'/mnt/Share':'rw' --memory=2G --user 99:100 --sysctl net.ipv4.ip_unprivileged_port_start=0 'nextcloud:latest' PostArgs: && docker exec -u 0 nxtcloud /bin/sh -c 'echo "umask 000" >> /etc/apache2/envvars' 2c3b5dfa03141bda7dbd795480db77ec70845af59c511b1ae910008bded9e6b8 Error: No such container: nxtcloud The command failed. It's sad if I'm too blind to do monkey see monkey do, but I'm stumped, really.

It's already using MariaDB. I had a problem with my cache drive, everything went down, turns out it was the database, but I hadn't suspected that before fiddling with NPM first, as that had just been updated and I noticed things not working post-updating that, rather than when MariaDB updated. So not sure what exactly happened, but Nextcloud was working perfectly with the config it had. I have to assume that maybe something got corrupted, despite its services being functional. I'll have a look at the Knex-container as you recommended. I've gotten this stuff to work before, I just ran against a wall trying to debug this and, well, finding a clue when you're frustrated isn't easy. I really appreciate you taking the time, thank you so much!

You are correct! When changed to http in NPM, the wordpress install is now accessible. That at least means that NPM works. So either my settings for nextcloud are off, just as they were with the wordpress install, or I guess nextcloud is just broken.. although it's updateable via command line and everything appears to function fine. Unless you can see anything obviously wrong, I think I'll just have to scrap the nextcloud and start over.... I do wonder what on earth has gone wrong though.

The wordpress test-site works via local logon, if that's what you wanted to verify? 🙂 Since they suffer from the same fault I think it serves the purpose for testing?

Config has been set to disallow local logon, so connection gets refused. Still the same result using 9444 instead of 444.

444 is nextcloud. 8083 is the test-wordpress. # curl https://192.168.1.101:444 curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to 192.168.1.101:444 Using linuxserver nextcloud container.

As nothing has been typed, both NPM and the Nextcloud container are in bridge mode, I don't see how I could input anything manually. The nextcloud container should forward all http requests to https. (As should NPM, by the way.) Here's doing it to the root IP: # curl http://192.168.1.101 <html> <head><title>302 Found</title></head> <body> <center><h1>302 Found</h1></center> <hr><center>nginx</center> </body> </html> # curl https://192.168.1.101 curl: (60) SSL: no alternative certificate subject name matches target host name '192.168.1.101' More details here: https://curl.haxx.se/docs/sslcerts.html curl failed to verify the legitimacy of the server and therefore could not establish a secure connection to it. To learn more about this situation and how to fix it, please visit the web page mentioned above. Here's connecting to the wordpress container that I set up to test - and the nextcloud docker respectively on both http and https: # curl https://192.168.1.101:8083 curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number # curl http://192.168.1.101:8083 # curl https://192.168.1.101:444 curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to 192.168.1.101:444 # http://192.168.1.101:444 sh: 13: http://192.168.1.101:444: not found But url's from the outside result in bad gateway though: 502 Bad Gateway openresty I'm sure I'm just missing something obvious but I've tried so many different configs now that I've lost count trying to get this working again.. and it HAS been working previously.

I tried that for my issue; # curl http://192.168.1.101:444 curl: (3) Failed to convert 192.168.1.101 to ACE; could not convert string to UTF-8 # curl https://192.168.1.101:444 curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to 192.168.1.101:444 Any ideas on what's going on here?

Just to sanity-check I changed both containers to br0 and gave them dedicated IP's. Nothing worked. Now changed both back to bridge and I'm getting bad gateway. I don't see from your table how that should be the expected result. I tried booting up a wordpress container and that also gets bad gateway.

Okay I give up. I've had NPM working for ages now, but suddenly I'm having issues. I've been changing networks and setup so much that it's laughable at this point and I'm probably only making myself confused at the moment. NPM > NextCloud is the goal. Current setup: Current forwarding rules: Using a random domain to test I get a refusal because HSTS is enabled, so presumably NPM is getting the traffic. I tried using NPM on bridge instead, but that resulted in Bad Gateway. I tried setting up a wordpress container to see if my Nextcloud install was b0rked - but that can't be reached, either. Clearly it's some simple mistake doing all this. As mentioned I've tried various config changes and I even tried putting both NextCloud & NPM on the same network to no avail. Again I probably screwed something up even worse by just trying a slew of different things.. I'm fairly sure I didn't use to have NPM on a dedicated IP either.. but here we are. Please advise as I'm sure it's simple and I've just gone and FUBAR'ed it. Been trying to bring it back after some DB corruption due to a MariaDB update erroneously made me think my old NPM setup was the cause and I rebuilt it.. clearly not well enough. So it's been.. a while.. now.

I'm sure there can be a myriad of other factors at play.. just figured since I've done nothing to change the container, other than adding a few more folder-mappings, that it might happen to others, too. After removing 600+ seeding torrents and restarting the container, it immediately re-added them all again. So I had to remove the .torrent files manually in the appdata directory too. Here's hoping it doesn't happen again. It's been rock solid otherwise.