thany

I've been thinking about this problem as well. A UPS is simply no good to handle the "AC resume" situation. In fairness, Unraid can't do anything about this either, nor can the server hardware. So just to re-iterate the scenarios: If power comes back before Unraid has started to shutdown - no problem. If power comes back while Unraid is shutting down - UPS sending a "power on" signal of any kind, will have no effect since the server isn't powered down yet. If power comes back after Unraid has shut down, but before UPS has turned off - UPS may or may not be able to send a "power on" signal. This part seems fragile across many different UPS models. If power comes back after Unraid has shut down, and after UPS has turned off - UPS may or may not automatically power back on, and this is something you would have to check with a manual test. I think the third scenario is the most common one. If the power is down for long enough to drain the UPS past a set threshold, the server will shutdown. After the shutdown, the server will be using maybe a few watts while powered off, and it's unlikely that this will drain the UPS further to 0%, causing it to shut off completely. This is also why the BIOS "power on after AC restore" is so utterly useless with a UPS, especially one that doesn't cut off power to the server completely. So it got me thinking. A watchdog? My current idea is to make a small raspberry pi, with some kind of minimal OS on with a script that just sends a WOL package to the Unraid server. Nothing else. It doesn't need to know about when AC fails or resumes, it can just send that WOL package every 5 minutes, all day every day. That's it. To be clear, this watchdog should NOT be on the UPS - that wouldn't make any sense. That would cause it to power up the server while AC hasn't resumed yet. But I wonder, is this really the best option to cover ALL scenarios? I guess any decent professional grade UPS can be configured to do all this, without the need for a watchdog. But hobbyists don't generally have that kind of money.

But again, for that I would need to know what to actually do in order to test if it still happens. I have no way of knowing atm, when or why this happens. And I kind of can't go without my dockers and VMs for along time - unfortunately I've come to rely on them working. Happened just now again. I just retry a few times and eventually it'll work. Could it be - hypothetically - that the web UI is just slow? Or that it's "asleep" and needs to be loaded again from swap memory or something? I mean, the browser claiming a site is unreachable just simply means it didn't respond in time.

Retesting is a problem, because for that I would have to know what triggers the problem. I mean, how can I trigger (and test) things if I don't know what I have to do... I wonder how it could be a hardware issue though. Like I said, a VM running on the very same server is perfectly reachable, at full performance. Might it just be a problem that isn't logged anything about? Something the underlying OS just thinks is normal perhaps?

I do approximately yes, it was somewhere between 15:00 and 15:30, today.

Sometimes my shares are "just" inaccessible for a little while. It's not because the drives are spinning up: the web UI is also inaccessible. It's like something needs to wake up, and it's not the drives. This has happened twice over the past month, while drives needing to spin up happens daily. The whole server isn't offline, as I can access a VM running on it perfectly fine without any performance dips. So the server wasn't asleep or rebooting or something. When these moments of inaccessibility happen, Windows claims the username/password is incorrect, so the server probably reports access denied (so it can report something, else it would just time out). My username/password are correct. So maybe "something" is denying access to the shares, and to the web UI at the same time. And also, for some reason, my browser goes to try to access the web UI via https, which of course doesn't work. I do not have HTTPS Everywhere. And then, a few minutes later, things just magically start working again. And I have no clue whatsoever what triggered this weird behaviour, and how to reproduce it. Can anyone suggest what I can try to mitigate this? Or perhaps confirm if it's a bug? unraid-diagnostics-20250830-1519.zip

If I remove that empty line, I see in the logs a lot of git diffs flying about, first of all. I wonder how that happens. Why does a docker need to concern itself with anything git? And then also why would it need to show diffs?... This is really confusing, and without any explanation about it. After all those diffs, it's erroring out again though. (see attachment - unraid forums has decided to mess up the formatting) Something about a cache path, it looks like. No idea what it's on about. Can't the dockerfile/config just use whatever cache path is appropriate without us users having to supply one manually? Or something else is broken? logs.txt

Oh here we go, the compose UI also has logs. It says this error for BOTH dockers: ``` pixelfed-web | 2025-03-27 14:00:15 +00:00 - [entrypoint / entrypoint.sh] - ============================================================ pixelfed-web | 2025-03-27 14:00:15 +00:00 - [entrypoint / entrypoint.sh] - Executing [/docker/entrypoint.d/02-check-config.sh] pixelfed-web | 2025-03-27 14:00:15 +00:00 - [entrypoint / entrypoint.sh] - ============================================================ pixelfed-web | 2025-03-27 14:00:15 +00:00 - [entrypoint / 02-check-config.sh] - 👷 Running [dottie validate --file /var/www/.env --ignore-rule dir,file --exclude-prefix APP_KEY --no-fix] as [root] ) - parseCompleteAssign 13-27 14:00:15 +00:00 - [entrypoint / 02-check-config.sh] - (stderr) Error: failed to load file: unexpected token at line 5: SPACE( pixelfed-web | 2025-03-27 14:00:15 +00:00 - [entrypoint / 02-check-config.sh] - (stderr) Run 'dottie validate --help' for usage. pixelfed-web | 2025-03-27 14:00:15 +00:00 - [entrypoint / 02-check-config.sh] - ERROR - ❌ Error! pixelfed-web | 2025-03-27 14:00:15 +00:00 - [entrypoint / entrypoint.sh] - ============================================================ pixelfed-web | 2025-03-27 14:00:15 +00:00 - [entrypoint / entrypoint.sh] - Sourcing [/docker/entrypoint.d/04-defaults.envsh] pixelfed-web | 2025-03-27 14:00:15 +00:00 - [entrypoint / entrypoint.sh] - ============================================================ pixelfed-web | 2025-03-27 14:00:15 +00:00 - [entrypoint / 04-defaults.envsh] - Sourcing /var/www/.env pixelfed-web | /var/www/.env: line 84: $'\r': command not found pixelfed-web | /docker/helpers.sh: line 254: pop_var_context: head of shell_variables not a function context pixelfed-web | /docker/entrypoint.d/04-defaults.envsh: line 13: pop_var_context: head of shell_variables not a function context ``` I don't know what it means by `SPACE(` on line 5. That's where the domain name is. There are no spaces. Then it also complains about line 84, which is an empty line, just like in the instructions 🤨

I had to remove these lines from the compose file: ``` # Used by [proxy] service LETSENCRYPT_HOST: "${DOCKER_PROXY_LETSENCRYPT_HOST:?error}" LETSENCRYPT_EMAIL: "${DOCKER_PROXY_LETSENCRYPT_EMAIL:?error}" LETSENCRYPT_TEST: "${DOCKER_PROXY_LETSENCRYPT_TEST:-}" ``` Then it started to work, after forgetting to set the TCP port to something other than 8080. Not sure why it wants to concern itself with Let's Encrypt, because that is indeed up to the proxy service, which isn't included in the stack. And probably for good reason: if you have a proxy, you would want it separately, which I have. So all's good, but maybe remove those lines from the instructions as well. Secondly, I was mystified about the APP_TIMEZONE variable. It is not mentioned on the pixelfed documentation, and it's unclear what format is expected. I just willy-nilly put in "Europe/Amsterdam" and so far it doesn't error out. So then the stack was able to start. After starting, you instruct: > In the docker tab of the unraid UI click on the new pixelfed-web container and click ">_ console" this will open a new window that contains a console shell of the docker container But that part isn't working. For BOTH the web and worker dockers, BOTH the console and log open a split second and then close. The status on the right says "Restarting (127): 47 seconds ago" for both, even minutes after creating, so I guess something is wrong, but without a console or log, I have no way of knowing what. It doesn't seem to drop a logfile in the appdata directory either, so I'm hoping your guess is *not* as good as mine, but better

Just a quick headsup, the link for install instructions for Ghost is broken. I just need to know what the default admin login is, so I can proceed. I'm sure it would've been mentioned there.

This defeats the purpose of having a separate docker for the database of an application. Authors of dockers for applications are generally reluctant to embedding a database server within the same docker, and recommend to run a database server separately. I understand why, but having an entire mariadb instance for each database totally defeats their reasoning, and a general sense of effeciency.

All my started dockers get their own IP address, like 172.17.0.5 or something. Network type is `bridge`, which is obviously the default, so it must not be terrible at least. All good and well, but there's a problem with this. I can't know if they are guaranteed. So I've got a MariaDB docker that, of course, I need access to from other dockers. So I configure those dockers to connect to 172.17.0.5 as the database host. Now, if that 172.17.0.5 was guaranteed, it would be fine. But it doesn't seem to be guaranteed, nor configurable. I had it change on me when reinstalling a docker, which makes me sceptic about what happens when a docker gets updated. I haven't had an update for that one yet, so I don't know what'll happen. If only I could force the IP address of a docker to be statically whatever I need it to be, I would feel more confident to use that IP address in configs of other dockers that need access to it. I have tried to use `localhost` as the database host, but that doesn't work, and causes dockers to try to connect to themselves, instead of the MariaDB docker. I haven't tried yet to use a name, rather than an IP address, perhaps unraid has a mechanism to resolve a name to one of those internal IP addresses. But I don't know if this mechanism is there in the first place, and even if it is, I don't know what it expects. Now, I'm sure one docker connecting to another is not an otherworldly scenario. Am I even doing it correctly in the first place?

Got there in the end. I think the random password generation was a huge mistake to include if it never shows what it actually generates. It would have been better to create a root account with no password, than to create a root password with a magical unknown password. Anyway, the solution. 1. Edit the docker 2. Enable advanced view (top-right corner) 3. In `Post Arguments` enter `--skip-grant-tables` 4. Apply 5. After the docker restarts, open its console 6. Run `mariadb` 7. Run `flush privileges;` 8. Run `alter user 'root'@'localhost' identified by 'new_password';` 9. Run `exit` twice. 10. Edit the docker again 11. Enable advanced view again 12. In `Post Arguments` remove `--skip-grant-tables` 13. Apply And you're done. Now you can feel free to go into the console and do your admin tasks like normal. Again, this shouldn't be neccesary. A docker should not be designed to lock an admin (that's us) out of their administrative tasks by using a password that literally nobody knows, or could ever know.

Unfortunately this no longer works. I don't know if it ever did, but I assume it did. First of all, the command is now `mariadb`, not `mysql`. Secondly, the custom.conf file doesn't exist, and creating one with the required contents doesn't do what you said it would: ``` [mysqld] skip-grant-tables ``` ^That would be the *entire* contents of custom.conf. Result: ``` $ mariadb ERROR 1045 (28000): Access denied for user 'UNKNOWN_USER'@'localhost' (using password: NO) $ mariadb -u root ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO) $ mariadb -u root -p Enter password: ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES) ``` So what is the *actual* way to (re)set the root password, please?

I got a problem. I installed this docker with random password generation enabled, as is the default. But I couldn't find the password in the logs anywhere. It's supposed to be printed in the log, but it rightly isn't. So I disabled random password generation and entered my own, as per the instructions. That password is not accepted. Ehm... Okay? It's definitely correct, so if the password I told it to have, is not correct, then what is? I have already tried to reinstall the image, hoping that it would re-setup the root password, which is does not. I basically just want to add another database. At first I assumed one could do that by editing the username/password/database in the docker settings, and it would pickup the new values and create a database accordingly, but it seems those values do very little more than nothing after initial installation. But before that I need to have the root password. How do I get that? I mean actually. So not by looking at the logs, because it's not there.

Alright, so the *only* reason this doesn't happen automatically, is to enable downgrading? Makes it feel a bit naff for fresh 7.x installations - they apparently can't be downgraded to 6.x if they wanted to for whatever reason. It seems to be that if you upgrade from 7.0 to 7.0.1 or similar, it is indicative that you want to stay on 7.0 and the pool upgrade can occur automatically, just like on a fresh 7.0 install. And, is it important to upgrade? I mean, it's working atm... What extra features do I get? Does it go faster? Do we finally get to cache metadata for instance?