zero_koop

Welcome! In many ways you sound a lot like me: similar longevity, similar experience with Unraid, and similar docker containers. In fact, the reason I found your post was searching for threads about Lobe-Chat. It caught my eye the other day and I was curious about it, but honestly I don't know much about how the AI stuff works. Can I ask you a question about it? Once you get Lobe-Chat up and running do you have to train the AI or does it come built in or does it require a subscription to a paid AI service (i.e. ChatGPT v4)?

@trurl Thank you! That's great news, and very convenient when I am in a tight spot dealing with a power outage. I'm still curious as to why I find my server in an odd state when I turn on the monitor during a power outage. Why is it not at the prompt screen and instead is seemingly executing some command that does not display until I hit the Enter key to display the next line. But you have answered my original question. The most likely answer is that I hit the power button and shut it down and then forgot that I tried that. I will continue to test and look into my other question but it is much less urgent now that I have a safe backup method of shutting down the server.

Well we just had another power outage so I got to test things again. Basically the exact same thing happened as last time. When I turn on my sever it boots up and I'm left at the login screen. As far as I know it should sit there until told otherwise. But whenever I view the server after a power outage it is at this line: Starting NTP daemon: /usr/sbin/ntpd -g -u ntp:ntp If I hit enter I get more and more lines to reveal until I get "Tower login:" But whatever I type here does not appear. I tried typing in a login and password anyway, but no luck. However if I continue to hit Enter it will show more lines and will eventually show a line that says "root" or my root password (words that I typed in previously). So for some reason the screen is very delayed in displaying what it should. Then I tried hitting the power button on my case and this initiated a safe shutdown! I probably tried this during the first power outage, but forgot. So can anyone confirm that hitting the power button will tell Unraid to initiate a safe shutdown? If so, that is a nice feature that I wasn't aware of and very useful for this type of situation. So after power came back on I decided to run some tests. First I was able to successfully boot my server, login from the command prompt and issue the "powerdown" command to safely shut it down. Same result as with the power button. Then I decided to simulate a power outage by unplugging my UPS from the wall. The server did not react at all (as I would expect), but this is different behavior than what I saw during the real power outage. So bizarre! Here are my UPS settings. It appears to be disabled (I've not changed them from the default). Setting this up sounds interesting, but the manual page is 47,000 words so I guess I'm not THAT interested 😉.

My home lost power the other day for a significant amount of time. I have the Unraid server connected to an UPS so in theory there was no power interruption. But my plan in this case was to use my phone (router and switch also retained power) to manually shut down the server for a clean shut down. But several strange things occurred while the power was still off that I'm having trouble understanding: Initially my WiFi router seemed to be off. I don't know why, simply unplugging and plugging it back in seemed to get it working. Once my phone was connected to my WiFi router again I was not able to use my browser shortcut to connect to the Unraid server. Why? Again, my router, switch, and server were all powered on and connected. Do routers require an internet connection to route internal traffic? This seemed like a good plan, but it didn't work and I'm trying to understand if it was a fluke or if I need a better plan. Normally I do not have a monitor and keyboard connected to my server. So I plugged them in hoping to issue a shutdown command. When the monitor turned on it did not show a command prompt. I don't remember the exact message, but it looked like it was in the middle of running something. I hit "Enter" and Unraid showed me the next line of information. I hit "Enter" again and again and it kept showing me more lines of information. Finally it asked me for my login information (username). I tried entering "admin" or "root" but it just kept asking me for the login. So I tried the password and eventually it stopped responding. Then, suddenly it said something to the effect of "initiating a clean shutdown procedure" and then the computer turned off. Actually the fans and case lights remained on, but this is a known oddity I've always had when I sometimes shut down the server (the fans and light remain on until I kill the power). Any idea what was going on? Did Unraid self-initiate the shutdown but somehow got stuck until I did something? When power returned and I was able to turn the server back on everything looked fine. Unraid was not running a parity check (as it normally would after an unclean shutdown) and it seemed like it did initiate a clean shutdown on its own as far as I could tell. I realize that the Unraid manual talks about configuring a UPS for auto shutdown, but I certainly did not set that up.

I just wanted to update my thread with some thoughts for anyone else who is looking for this solution. I used NextcloudPi for about 1.5 years and I was not ever really comfortable with it. The app is very unstable, prone to breaking upon updates (I never learned the lesson of just leaving the app alone when it is working and avoid updating), and just generally required a lot of babysitting to keep working on everyone's phones. Keep in mind I am referring only to NextcloudPi and not regular Nextcloud which looked too complex for me to setup. Honestly, the main reason I went with Nextcloud to begin with was because it offered the possibility of syncing photos while outside of my LAN. But I never really tried to get that portion of it working anyway. After having to reinstall the docker a few times over the past 1.5 years I started getting a weird file permission issue that never affected me before and I couldn't fix it so I had to move on (reinstalling didn't work). I have now been using Syncthing for the past month or so and I really love this app (thanks to @Aran for the suggestion). It was pretty simple to get running, is a super lightweight app, seems really stable, and the Android app just works without the need to babysit it. Honestly this is exactly what I was looking for as a replacement to Plex Camera Upload. The only downside is that I cannot upload outside of my network (only really an issue when I'm on vacation) but the stability of the app more than makes of for that. When I'm on vacation I just temporarily turn on uploading to Google Photos.

I am interested in making FreshRSS available to my phone when I am outside of my network, but honestly I have no idea where to start. Is this something I need to research at a level beyond FreshRSS or is this something I can implement just for FreshRSS? I know my Plex server is available outside of my network but I assume that is because you technically connect to a Plex.tv server which then connects to your home server and that is why I've never had to do any special setup to make Plex available outside of my network. Is that the difference? If someone could point me in the right direction I would appreciate the nudge.

@SmartPhoneLover, just wondering if you ever got Readrops working. Like you I got FocusReader working but can't get Readrops to connect. For what it is worth, this is the inputs I am trying (I think yours are wrong, but then again mine don't work either): Account url: http://server_ip:port/api/greader.php Account name: FreshRSS Login: username Password: API password (Settings > Profile > API Management) If I get this working I'll probably make another post for newbies like me, but to get you started here is the manual (took me forever to find this): https://freshrss.github.io/FreshRSS/en/ or more specifically, this page:https://freshrss.github.io/FreshRSS/en/developers/06_GoogleReader_API.html

Thank you! Yes, it was Unraid using port 80 and thanks because I didn't know that it was safe to use ports above 8080 because that was also in use, so I used 8081 and it worked! Much appreciated.

Hi, I'm looking to do a fresh install. When I click "install" from the app store I get this message: The docker template has port 80 filled in. From what I'm reading in this thread it seems that port 80 is fine. I only have a basic understanding of ports and I believe port 80 is HTTP so that makes sense to me. But am I supposed to use something else? I'm just cautious because I don't want to accidentally break my ability to access Unraid from the browser to fix any problem I create. Other than the port question, all of the other docker settings seem pretty straightforward. Thanks.

I've noticed that one of my Shares has a different owner and group than the other shares on my server. I'm not sure why and I'm wondering if that is related to a permission issue I'm having with files in that share. Here are my shares and permissions: root@Tower:/mnt/user# ls -l total 20971520 drwxrwxrwx 1 nobody users 448 Oct 8 21:18 Documents/ drwxrwxrwx 1 nobody users 0 Oct 8 21:18 Music/ drwxrwxrwx 1 root root 216 Oct 9 14:59 Nextcloud/ drwxrwxrwx 1 nobody users 0 Oct 8 21:18 Photos/ drwxrwxrwx 1 nobody users 0 Oct 8 21:18 Videos/ drwxrwxrwx 1 nobody users 212 Mar 21 2021 appdata/ -rw-rw-rw- 1 nobody users 21474836480 Oct 9 15:08 docker.img What could cause the Nextcloud share have a "root" user while the rest are "nobody"? Is there any risk to running this command? chown nobody Nextcloud/ (if needed, please correct my syntax as I have never used the chown command before)

I am now back up and running with Nextcloud, but am still experiencing the original issue that started all of this about a week ago. The issue is that I used to use another docker DirSyncPro to move files (phone camera photos) out of the Nextcloud directories and into another Unraid share where a third docker (CrashPlanPro) could see them and upload them. For whatever reason I could never use Windows Explorer to browse the Nextcloud files but DirSyncPro could so that's why I came up with this setup. I have an idea for a solution, but I am new to the concept of modifying file permissions and I have no insight into how this might affect Nextcloud. This is how my Nextcloud share looks right now: root@Tower:/mnt/user/Nextcloud# ls -l total 2 drwxr-xr-x 1 root root 808 Sep 29 06:40 bin/ drwxr-xr-x 1 101 103 440 Oct 9 10:36 database/ drwxr-xr-x 1 root root 104 Oct 9 10:37 docker-startup-backups/ drwxr-xr-x 1 root root 248 Oct 9 10:32 etc/ drwxr-xr-x 1 root sshd 1456 Sep 29 06:41 ncp/ drwxr-x--- 1 sshd sshd 800 Sep 29 06:39 nextcloud/ From what I'm understanding above (again, I'm new to permissions) is that only the file owner (sshd?) and members of the sshd group can read the nextcloud directory (the camera files are nested several levels below this directory). All other users (including whatever user DirSyncPro runs under) have no permissions. I've already attempted to use the Tool > New Permissions tool on this entire share which fixes the DirSyncPro issue, but breaks Nextcloud. I presume this is because it changes the user from "sshd" to "root". So my idea is: what if I just update the permissions of the nextcloud directory to be: drwxr-xr-- 1 sshd sshd 800 Sep 29 06:39 nextcloud/ That would give read permissions to "all other users" including DirSyncPro. Does that make sense? Any other suggestions? Again, I'm simply trying to get back to the situation I had about 2 months ago and had been working for years. I never had to go through this process before and I'm not sure what changed that is making it necessary now.

Well that was easy! Thanks so much and this is a very useful bit of knowledge to have. I was able to downgrade but Nextcloud is giving me a permission error in the log, which probably means that my earlier attempt to overwrite the file permissions messed this up. So I'm just going to wipe out Nextcloud and start fresh with a whole bunch of new lessons learned! I'm curious to know if others had this problem and how to tell if it will be safe to update to other versions in the future. I guess I could use a trial and error approach with that, but that is not ideal.

Ok, after seeking a little help on another thread, I believe my issue is just with the NextcloudPi docker. According to others, "Docker containers have the software they use installed internally to the container. If there is a problem with the PHP version then it is a container issue and nothing to do with Unraid." So to me (and my limited knowledge) that says that this entire new version of the docker is messed up, because anyone upgrading to it would get this error. I'm probably missing something, but the question is how to fix this? How do I downgrade the version of PHP within this docker? Or, how can I downgrade the entire docker to an earlier version that works for me?

I am having trouble with a docker, but I believe the issue is stemming from my recent upgrade to Unraid 6.10.3. With the docker NextcloudPi I am getting the error: What I want to figure out is: did this version of PHP get installed with an Unraid OS upgrade? About a month ago I had an earlier version of Unraid installed but about a week ago I installed an updated version (presumably 6.10.3 but I don't know how to go back and confirm). While troubleshooting my Nextcloud issue I downgraded back to 6.10.3 to see if that would fix the PHP issue, but it did not. So I'm still trying to figure out how to solve the issue. Unraid doesn't allow me to downgrade back to an even earlier version and I don't know how to downgrade dockers. So for now I'm just trying to figure out how to downgrade PHP, unless someone else has other ideas. Diagnostics attached. Thanks for your help! tower-diagnostics-20221008-1415.zip

I didn't get a response in that thread, but I was able to solve the problem myself. I've not used it before so I had to do some research, but I was able to fix the permission problem by running the Tools > New Permissions tool on my Nextcloud share. I don't know what caused the issue in the first place, but it is solved for now. Thanks for your help, but does NOT appear to be a DirSyncPro issue!

Hello. I am also seeking assistance for an issue involving NextcloudPi and DirSyncPro dockers. I started with the DirSyncPro help thread, but after some investigating we think the issue may stem from NextcloudPi. I have NextcloudPi installed on a share called "Nextcloud" with nothing else on the share. The issue I am facing is that DirSyncPro can no longer see my phone camera files that I've backed up to the directory /mnt/user/Nextcloud/nextcloud/data/username1/files/InstantUpload/Camera. I used to be able to see these files and DirSyncPro would copy them to another location automatically, but something changed and DirSyncPro can only see down into the level of: mnt/user/Nextcloud/nextcloud/. Looking at the permission for some of the directories in the Nexcloud share I found: root@Tower:/mnt/user/Nextcloud# ls -l total 3 drwx------ 1 root root 808 Aug 16 18:06 bin/ drwxr-xr-x 1 101 102 440 Sep 5 09:55 database/ drwxr-xr-x 1 root root 288 Mar 11 2022 etc/ drwx------ 1 root sshd 1496 Mar 7 2022 ncp/ drwx------ 1 sshd sshd 776 Mar 7 2022 nextcloud/ My helper in the DirSyncPro thread wondered why the user and group are "sshd" for the nextcloud/ directory. The sshd user and/or server process is a bit beyond my understanding of Linux. But I suppose my first question is: does this output look right? ------------------------- edit: solved, for now I've not used it before so I had to do some research, but I was able to fix the permission problem by running the Tools > New Permissions tool on my Nextcloud share. I don't know what caused the issue in the first place, but it is solved for now and I'll probably return to the thread if it happens again. --------------------------- edit 2: after I made this fix above, DirSyncPro worked again, but before I started up Nextcloud again I decided to update Unraid to 6.11.1 and apply the latest docker update for NextcloudPi. Unfortunately these actions have resulted in breaking Nextcloud. I don't know which of these 3 actions broke Nextcloud, but now I get the error: I am doing a little more testing/research, but I'd be curious to know if it is possible to downgrade the NextcloudPi docker.

Perhaps. I am using NextcloudPi.

Good idea! So... the results I got are confusing: When I set the DirSyncPro "Source Directory" to "/mnt/user/Nextcloud/nextcloud/data/" (three levels lower than what I want) I was not able to see any folders when viewing the "/sourcefiles" folder within the DirSyncPro app. However, when I set the DirSyncPro "Source Directory" to "/mnt/user/Nextcloud/nextcloud/data/usename1/files/" I was able to see the folders beneath it within the DirSyncPro app! So I was able to see down to "/Nextcloud/nextcloud/data/username1/files/InstantUpload/Camera". While poking around in another docker that I have installed (CrashPlan) I notice that app also cannot see down past the "/mnt/user/Nextcloud/" level. Perhaps this speaks to a larger issue with my Nextcloud share, but I'm not sure where to turn to next if it is, besides maybe a permissions issue. ------------------ update: this is the output of the "ls -l" command at the "mnt/user/Nextcloud" level: root@Tower:/mnt/user/Nextcloud# ls -l total 3 drwx------ 1 root root 808 Aug 16 18:06 bin/ drwxr-xr-x 1 101 102 440 Sep 5 09:55 database/ drwxr-xr-x 1 root root 288 Mar 11 2022 etc/ drwx------ 1 root sshd 1496 Mar 7 2022 ncp/ drwx------ 1 sshd sshd 776 Mar 7 2022 nextcloud/ I'm not super familiar with Linux commands, this looks like only the file owner has any permission to the /nextcloud folder. Not sure if that is a problem or not. As far as I know the DirSyncPro docker is also running as the root user.

My docker settings are: Container Path: /sourcefiles Host Path: /mnt/user/ So basically DirSyncPro can see all of my shares including the share named Nextcloud. And it can see a single folder level down into that share until it stops strangely. But if you are asking if the share is located on the cache or not I have "use cache pool" set to "no". Also of potential note is: I have never been able to use Windows Explorer to browse the contents of the "nextcloud" folder on the "Nextcloud" share. I've always received a "you do not have permission to access" error. I wonder if this permission issue, which never affected DirSyncPro is now affecting the docker.

Hello. I am having an issue with DirSyncPro. Things were working fine the last time I checked (early August), but when I try to run the Analyze step I get an error saying the source folder doesn't exist. Sure enough, if I modify the job to re-pick the source folder I can browse down a few levels to /sourcefiles/Nexcloud/nexcloud but there are no files or folders beyond that. However, there actually are files and sub-folders there and I've verified that not only with Nextcloud, but with the terminal command line. The folder I want to select is: /sourcefiles/Nextcloud/nextcloud/data/username1/files/InstantUpload/Camera Within that folder are all of my recent photos synced using Nextcloud. Why can't DirSyncPro see these folders anymore? I double checked all of my docker settings but can not figure out what needs to change as it had been working fine for months if not years.

Leave it to me to finally ask about an issue just after it has been resolved. That's great! But this has been an issue for a while for me. So either this is just a coincidence or I'm referring to another issue...

I have a question about what keeps happening whenever a new version of the docker is published. Every few weeks I'll check in on the docker and notice that it is eating up 50-60GB of space! For what it's worth, the space is taken up by files in this folder: (\appdata\CrashPlanPRO\conf\tmp) Whenever this happens, I check to see if there are updates to CrashPlan docker and 100% of the time there is. And if I pull up the CrashPlan WebUI I see some sort of error saying the app couldn't be updated. So I update the docker and it resolves the issue (tmp files are deleted). But sometimes (before I fix this docker) this causes issues because it uses up so much space on my cache drive that Plex and other dockers start failing. I'm wondering if this is expected behavior, or do I have something on CrashPlan misconfigured. Or, as a last resort, can I sign up to be notified when new CrashPlan updates are pushed. I realize that the issue may actually reside in CrashPlan servers demanding use of the new version, and isn't directly tied to the actual docker being updated.

Thank you so much, I found the culprit! And thanks to everyone else as well, I really appreciate it. The files that were taking up space were in my Deleted Files bin in Nextcloud! Roughly 26GB of deleted files. Nextcloud is relatively new to me so I didn't know it was keeping my files like that. I need to look for a setting that auto-deletes after 30 days, but otherwise I'll have to remember to empty my recycling bin. 😜

I cannot reconcile a few of these numbers. What I don't know is if this is normal or not. Here are some stats: Cache drive 1 size: 128GB Cache drive 2 size: 240GB filesystem: btrfs reported "size" on Main screen: 184GB what is this about? Shouldn't it just be 128GB? as per below: 98+29.5= ~128GB reported "used" on Main screen: 98GB reported "free" on Main screen: 29.5GB reported utilization for drive 1 in the popup system warnings: 97% how is this calculated? 98/128 = 76% or 98/184 = 53%, neither of which are close to 97% What if I told all of my shares to NOT use the cache drives, then invoked mover? Would that clear them out and would doing that be helpful in diagnosing the situation? Just to confirm my earlier calculations, I browsed to the "cache" network drive, used Windows Explorer to calculate the size of everything in the folder and the total was 55.6GB.

Here is the Diagnostics. tower-diagnostics-20210718-0827.zip