7hr08ik

I figured it out. DuckDNS can be used with sub-subdomains. Edit SWAG Docker as so; Then reboot the container, follow loggs to see it updating DNS records etc. Now I am able to use subdomains, and access immich; I'll set this as the answer to help any future peeps

Would i be better off buying a domain, and running everything in subdomains instead?

My SWAG config is as follows

Hey, I'm having some problems getting Immich accessible via my SWAG proxy. Firstly, yes my SWAG is setup correctly, and up to date. I have Jellyfin running and accessible through my domain, so IUm pretty sure it's running just fine. I have everything setup through duckdns as so; mydomain.duckdns.org/jellyfin (This works just fine) mydomain.duckdns.org/radarr (This works just fine) mydomain.duckdns.org/sonarr (This works just fine) mydomain.duckdns.org/immich (Seems borked) I am not using subdomains because I cant get them to work. Only by editing the site configs, can I get things to work. I'm not too good at web proxy stuff. I know the proxy is working, because if i change anything, I get the nginx error page. But when i have it set to point to the correct port, I am met with an empty blank page. If i check the page source, it is identical to the page source for the locally accessed immich page (192.168.1.x:8282) What am i missing? I just want to use immich and have it run through my SWAG setup. Any help is very much appreciated.

Should we be worried? Or are we just waiting for a plugin update?

Figured it out

Sorry to be a moron....but how do I revert back?

Hey guys, need some help... Updated the container today. It wont boot up anymore. I run NordVPN, and everything has been running just fine for the past ... months/years... Today I get the following... 2023-03-30 11:33:59.588541 [info] Host is running unRAID 2023-03-30 11:33:59.616601 [info] System information Linux 6c0837b709c6 5.19.17-Unraid #2 SMP PREEMPT_DYNAMIC Wed Nov 2 11:54:15 PDT 2022 x86_64 GNU/Linux 2023-03-30 11:33:59.648620 [info] OS_ARCH defined as 'x86-64' 2023-03-30 11:33:59.675093 [info] PUID defined as '99' 2023-03-30 11:33:59.708465 [info] PGID defined as '100' 2023-03-30 11:33:59.758393 [info] UMASK defined as '000' 2023-03-30 11:33:59.787916 [info] Permissions already set for '/config' 2023-03-30 11:33:59.817953 [info] Deleting files in /tmp (non recursive)... 2023-03-30 11:33:59.852272 [info] VPN_ENABLED defined as 'yes' 2023-03-30 11:33:59.879422 [info] VPN_CLIENT defined as 'openvpn' 2023-03-30 11:33:59.908262 [info] VPN_PROV defined as 'custom' 2023-03-30 11:33:59.944211 [info] OpenVPN config file (ovpn extension) is located at /config/openvpn/ch337.nordvpn.com.udp.ovpn 2023-03-30 11:33:59.994356 [warn] VPN confi 2023-03-30 11:33:59.994416 guration file /config/openvpn/*****.nordvpn.com.udp.ovpn remote port is missing or malformed, assuming port '1194' 2023-03-30 11:34:00.025007 [info] VPN remote server(s) defined as '***.***.***.**,' 2023-03-30 11:34:00.051578 [info] VPN remote port(s) defined as '1194,' 2023-03-30 11:34:00.077905 [info] VPN remote protcol(s) defined as 'udp,' 2023-03-30 11:34:00.107301 [crit] VPN_DEVICE_TYPE not found in /config/openvpn/*****.nordvpn.com.udp.ovpn, exiting... ** Press ANY KEY to close this window ** How can i add VPN_DEVICE_TYPE to the config? I have tried re-downloading configs. I have tried multiple configs from Nord, and I always get the same response. Deleted, and reinstalled the container. Tried with a clean appdata folder (renamed original and allowed it to recreate)

Been doing some reading and i think im gonna grab LSI 9211-8i card and some SAS>SATA cables. Then keep the parity and cache drives on the mobo, put the array drives on the card?

Oh sorry. Yes everything runs fine. All my dockers do as they should, plugins work as intended. Backups from other systems to the server run great. There has only been 2 issues for me, ever. This current issue, of random non-starting shares, and one other. I added a second cache drive (same size and even model as current cache) but when starting the system, the dual-cache would fail to start. So i just removed the second cache drive and forgot about it. But the more time I spend figuring this all out, the more I think it's related to the cheap HBM card I have installed. Unfortunately, due to the random nature of my problem, it is hard to definitively change and test any possible fix. The only thing I can do is replace the HBM card with something a bit more reputable, and see if my issues go away. (After a few weeks/months)

Yeah, everything with duplicati works great and has done for over a year now. Even restored from it a time or 2

I have Duplicati set to backup from my rig to unraid. It runs fine, as far as i know.

I dont think so. I have plugins, and dockers, but they wont do anything until after its all booted up. Apart from that I have my other rig, that backs up to there, but thats all SMB, so shouldnt really matter if the location doesnt exist yet. I do have a small cheap chineezium HBM in there (PCI-E, 2xSATA, and even an IDE) . If thats where my cache is installed, then i think we have our culprit. Perhaps that would explain the randomness of the fault

OK, so i've removed the erroneous .cfg files. Now i just have 1 for each of the shares I have.

Hi, I know the shares not mounting is the issue. My problem is that it is not a repeatable issue. For instance, yesterday the system booted up and gave me issues. Today, the system booted up, and not a single problem. And the weirdness of how a reboot, will always, every time, fix the problem. I think I know what those shares are from. I just looked at them, and they are all random names (blue, shallow, carp, etc) There was a time, a long time ago, that i used the anti-ransomware plugin, and if memory serves, it would create a while bunch of new shares/files/folders. Am I just to simply delete all the unwanted config files?

To clarify, I turned the system on, found the shares and docker had not started up. Got the diagnostic. Rebooted. And everything is OK. What could possibly be happening? If it was my car, I would be thinking the cold is making the starter motor seize up.

Aaaaaaaand its back! System was shutdown overnight. Came home from work, and started the system as I do everyday. Shares and docker are not starting up. I've attached a diagnostic. I did remove S3-sleep, and this seemed to do the trick for a while. missing-shares--hal-9000-diagnostics-20210113-1726.zip

Hey guys, Forgive me if this is in the wrong place. Please move if it is So, recently I've been having a couple of issues. And long story short, it turned out to be one of my installed apps. S3-Sleep, was causing a bug for me, where my shares and Docker, would not start up from a cold boot after an S3-Sleep shutdown. I only realised this app was the problem, after going into the apps menu, and looking at my installed apps, there was the little exclamation(!) mark. If i wasnt curious i would have not found that, and would probably still be looking for my fix. I have had the S3-Sleep app installed for so long, the issues have been found and noted, after I had it installed. So, I never saw the known issues warning. I'm just thinking that I only found S3 has issues because i went looking to see if there was anything, and not becasuse i was made aware of the known issues. Why would i ever need to go back to the app install page? Unless i was curous, fed up, and bored? My thought would be for Fix common Problems, (or the Plugins update) to warn users of newly found issues. Could include an "ignore this warning".

So, i just checked the app store, and theres a mark against S3 Sleep. Apparently it has issues. Perhaps thats my problem

So, i shutdown, and started up again. No issues at all.

So, if i do infact sit here for an hour and reboot the system, again and again. Cancel the parity check, try with and without the FTP from my phone. Could i break anything? I mean if it does, again, not start up the shares and docker, could i do damage to anything? I mean, could i be risking losing the shares, or corrupting the dockers? I just want to be certain, its only after cold boots. It might happen if i shutdown and startup, instead of a reboot. But i dont want to risk my data obviously

I'll try give that a go tomorrow, if i rememeber. Its just very strange that it only happens after the machine has been shutdown overnight. I would like to just sit here and do lots of reboots, and see if its repeatable at all. But I dont know if that gonna cause any more issues, or break something

I've added a second diagnostic. The first is from a cold state. She was shutdown for at least 18 hours. Failed on boot. The second (I have marked) is from a reboot, and gave me no issues (besides the obligatory parity check)

I did see that, and that is one of my shares. But i have no clue what it means. Obviously its telling me that "getxattr" has failed, on that share. But what is it? Is something i did, something i can fix? Is my drive screwed? And why is it only happening on a cold boot? Why not every boot?

So, My unraid machine, shuts down on a night. (Full shutdown not sleep) The past few days (maybe a week), i come home from work, turn the girl on, and when I goto use it, theres nothing there. So i log in to the webui, and my shares are unavailable, and the docker service failed to start. I dont think, I've done anything besides update, dockers, and plugins. I did tweak a couple of shares' SMB settings, but thats about it. I do run a tweak to my boot up. I run an FTP server on my phone, when th eserver boots up, she looks for my phone, and pulls the password. But this has been the case for 2 years now. I know, i know. But its no more insecure than anything else. It stays on my phone and is only accessible from my local network. It just saves me from having to log into the webui every bloody day, just to unlock the thing. The fix for this, seems to be to reboot. But obviously i dont want that. I've added my diagnostics, any help finding the culprit would be very much appreciated First (...1403) is after a cold boot. 18hrs shutdown Second (1506) is taken after rebooting the machine, and received no errors hal-9000-diagnostics-20201223-1431.zip hal-9000-diagnostics-20201223-1506(AFTER REBOOT).zip