DMills

Awesome, thanks!

Is this still being maintained? Last update has it at version v8.1.4, latest version is 10.0.1.

That did the trick, thanks so much!

Is there any way to make the startup scripts not cause the docker container to fail to run? I'm seeing this in the logs every time I try to start ownCloud. Hit:5 http://ppa.launchpad.net/ondrej/php/ubuntu focal InRelease Hit:6 https://mirrors.gigenet.com/mariadb/repo/10.3/ubuntu focal InRelease Reading package lists... E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct the problem. E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct the problem. *** /etc/my_init.d/20_apt_update.sh failed with status 100 I'd love for it to just start so I could exec in and run the dpkg line to fix it, but it dies every time. Any ideas on how to get past this?

I ended up adding an integer column called Dirty and set it to nullable, since there were already values present. I checked on the focalboard server and they're aware of the issue and so it should be fixed soon? Not running the container anymore so can't say for sure, sorry!

nvm, I fixed it myself, edited the sqlite3 database and added the Dirty column, it's working fine now.

Seems that focalboard is broken due to a bad db migration? [31merror[0m [2022-06-07 12:58:55.525 -03:00] Table creation / migration failed [31mcaller[0m="sqlstore/sqlstore.go:55" [31merror[0m="table schema_migrations has no column named dirty in line 0: INSERT INTO schema_migrations (version, dirty) VALUES (?, ?)" fatal [2022-06-07 12:58:55.525 -03:00] server.NewStore ERROR caller="main/main.go:145" error="table schema_migrations has no column named dirty in line 0: INSERT INTO schema_migrations (version, dirty) VALUES (?, ?)" Anyone aware of whether this is fixed yet or planned or? TIA

I'm sure I'm just blind, but what is the default username and password to get into this?

It's possible I guess, although the cache drives are just regular HDDs so they're as slow as the rest of the array, parity included. I just think my old quad core couldn't handle the load as well as this one can. I'm still going to try out the tuning plugin though

For me, it kind of depends on the system the drives are on. I know on my previous unRAID "server", I had a number of 8TB drives and it took upwards of 24 hours to finish the monthly parity check, mainly due to the machine being overtaxed by me with lots of containers running, and using the machine during that time. Now on my new server with 16TB drives, and lots more horsepower, I don't even notice the check is running until I go onto the server and see it's either running or finished. The parity check now takes around 26 hours or so, so there is no direct correlation from one size to the next, there are lots of other factors. I checked the prices and found the 16TB drives to be the best $/TB so went with them, parity check times be damned!

You're probably right, but I don't see it being reported anywhere using dmidecode. Oh well, as I said, an annoyance at worst.

FYI, got notified of an upgrade this morning, but receive the following error when trying to upgrade: plugin: updating: unassigned.devices.plg plugin: downloading: "https://github.com/dlandon/unassigned.devices/raw/master/unassigned.devices-2022.04.20.tgz" ... done plugin: bad file MD5: /boot/config/plugins/unassigned.devices/unassigned.devices-2022.04.20.tgz Tried multiple times, same issue

Exactly the same issue here, and moving away from Cloudflare's DNS servers fixed it for me as well!

Just tried again to install Nextcloud on my new server, no matter whether I choose, MariaDB or Sqlite, I get the dreaded 504 timeout error every time. I'm officially giving up on Nextcloud.