3 minutes ago, ffleps said:

Where is the correct location for me to save the DirSyncPro jobs I create to make sure they don't disappear??

They don't disappear usually, are you sure that the path for the config direcotry is mapped correctly in you Docker template?

 

Please note if it's set to /mnt/cache/appdata/... the data from the appdata share has to stay on the Cache and should not be moved to the Array or another pool.

 

Most likely the above is your issue.

 

3 minutes ago, ffleps said:

/mnt/local

I don't know what you mean with that, nothing should be mapped there in the container.

12 minutes ago, ich777 said:

They don't disappear usually, are you sure that the path for the config direcotry is mapped correctly in you Docker template?

 

Please note if it's set to /mnt/cache/appdata/... the data from the appdata share has to stay on the Cache and should not be moved to the Array or another pool.

 

Most likely the above is your issue.

 

I don't know what you mean with that, nothing should be mapped there in the container.

 

I don't have any movers, I don't use the cache > array approach on my NAS.

 

My pool is my main storage with 2 nvmes in raid 0, no movers / secondary storage configured.

An HDD is my secondary disk, which is not marked as secondary storage anywhere and I don't have movers configured anywhere (that is confirmed by the fact that none of the usual system directories on my main pool exist on this disk)

 

I'm using DirSyncPro to daily backup (copy/sync, not move) my Pool to Disk1.

 

It worked all fine, I opened the GUI, created the job, configured it, ran the analyzer and some manual triggers, setup the schedule, setup to start the schedule automatically on the Gui, then closed the Gui and setup the container/docker itself to auto-start on Unraid settings.

 

This is what I have on the container settings, the only thing I changed was the Source Directory to / and the permissions o read/write as I'm using this to backup my main storage to a secondary disk.

 

 

When I hit to save the job on DirSyncPro, it shows it's "home" location /dirsyncpro, which is where I saved the job the first time (but according to the screenshot above it seems the real location is /mnt/local?)

 

Edited December 14, 20241 yr by ffleps

Just now, ffleps said:

When I hit to save the job on DirSyncPro, it shows it's "home" location /dirsyncpro, which is where I saved the job the first time (but according to the screenshot above it seems the real location is /mnt/local?)

I don't know why it is /mnt/local in your case because if I try to install it from the CA App the default is:

2 minutes ago, ich777 said:

I don't know why it is /mnt/local in your case because if I try to install it from the CA App the default is:

 

Weird, I don't remember touching this anywhere. Is there a global config for this somewhere?

/mnt/cache doesn't exist on my NAS when I go to files.

 

I'm on Unraid 7.0.0-rc.1, maybe they changed this?

 

Anyway, if I don't have any movers this shouldn't matter, does it?

This time around I saved the config file on another place, mnt/user/appdata

Should this be ok?

 

Am I assuming incorrectly that the docker settings/configs (the job itself, the schedule auto-start, etc) should survive a system reboot, docker update, system update?

2 minutes ago, ffleps said:

Weird, I don't remember touching this anywhere. Is there a global config for this somewhere?

/mnt/cache doesn't exist on my NAS when I go to files.

Change it to /mnt/YOURPOOLNAME/appdata/... or /mnt/user/appdata/... both will work fine.

 

2 minutes ago, ffleps said:

I'm on Unraid 7.0.0-rc.1, maybe they changed this?

Definitely not.

 

2 minutes ago, ffleps said:

Anyway, if I don't have any movers this shouldn't matter, does it?

No.

 

2 minutes ago, ffleps said:

Should this be ok?

Yes, this is fine.

 

3 minutes ago, ffleps said:

Am I assuming incorrectly that the docker settings/configs (the job itself, the schedule auto-start, etc) should survive a system reboot, docker update, system update?

With the path set to anyhting like in the above mentioned it will survive a reboot, issue with your path /usr/local is that it is wiped every time Unraid is restarted.

1 minute ago, ich777 said:

With the path set to anyhting like in the above mentioned it will survive a reboot, issue with your path /usr/local is that it is wiped every time Unraid is restarted.

 

My setting is /mnt/local, not usr/local. And checking it, /mnt/local I can't see where it is located, it seems it's an "on runtime" place created on system boot, and somehow, it's where DirSyncPro is actually installed??

 

If this isn't a "on disk" location, then what's actually happening is that on system reboot DirSyncPro is just being reseted / reinstalled?

 

This is so confusing, I'll digg into my Unraid settings to see if I modified anything about docker installation (although I have other plugins installed and none are on this directory)

 

 

1 minute ago, ffleps said:

My setting is /mnt/local, not usr/local. And checking it, /mnt/local I can't see where it is located, it seems it's an "on runtime" place created on system boot, and somehow, it's where DirSyncPro is actually installed??

Sorry, typo.

 

The container installs DirSyncPro to /dirsyncpro in the container, if you set this path to /mnt/local on the host it will be installed there, if you now set the host path to /mnt/user/appdata/dirsyncpro it will be installed there.

 

2 minutes ago, ffleps said:

If this isn't a "on disk" location, then what's actually happening is that on system reboot DirSyncPro is just being reseted / reinstalled?

Deleted, that's why I wrote above you should set the Config dir to /mnt/cache/... or /mnt/user/...

 

3 minutes ago, ffleps said:

This is so confusing, I'll digg into my Unraid settings to see if I modified anything about docker installation (although I have other plugins installed and none are on this directory)

Yes, because this is definitely not the default path, maybe you played with the path when setting up the container and didn't noticed until now.

 

This path is inside the container:

if you set the host path to somewhere else on a non persistent location like in your case /mnt/local it will be wiped on a Unraid reboot.

 

The container installs dirsyncpro if not found to that directory and stores all config files there, so if it's set to /mnt/local everything will be wiped on a reboot, if you set to host path to somewhere persistent it will stay and work as intedned.

 

Hope that makes sense.

8 minutes ago, ich777 said:

Hope that makes sense.

 

Yes it makes sense, thanks for trying to help.

 

Weird thing is, this is my global docker settings:

 

I completely uninstalled DirSyncPro now and unraid reboot to try to install again.

Is there a "cache" somewhere that will try to install on that directory again? I'm installing it via the App official place inside Unraid, nothing manual.

 

Edit: I also deleted the /mnt/local after uninstalling DirSyncPro as everything was still there! Weird.

 

Edited December 14, 20241 yr by ffleps

2 minutes ago, ffleps said:

Weird thing is, this is my global docker settings:

As said above, you might have changed the path when setting up the container.

 

2 minutes ago, ffleps said:

Is there a "cache" somewhere that will try to install on that directory again? I'm installing it via the App official place inside Unraid, nothing manual.

No, is it now set to /mnt/user/appdata/dirsyncpro in the template?

 

3 minutes ago, ffleps said:

Edit: I also deleted the /mnt/local after uninstalling DirSyncPro as everything was still there! Weird.

What do you mean with that?

10 minutes ago, ich777 said:

No, is it now set to /mnt/user/appdata/dirsyncpro in the template?

 

Ok, I'm pretty sure I did something wrong the first time I installed it, as this time around the path when selecting to install was what you mentioned before, /mnt/POOLNAME/appdata/dirsyncpro

 

I installed it normally, was able to load my job from /appdata where I saved it before, changed some config, saved, analyzer + sync worked fine, restarted, container auto-started, opened Gui, job + schedulers are there.

 

All is fine now, sorry to waste your time, was totally something I did wrong, first time dealing with NAS/Dockers.

 

Thanks a lot for the help!

Hi,

I realized a weird behaviour with the portfolio-performance container today.

The container was installed and automatically updated from the repsective unraid image https://hub.docker.com/r/ich777/portfolio-performance. So far it ran without any problems, but today when starting up, I saw unexpected errors in the VNC session.

 

When I now try to login using the WebGUI, i see an error message, pointing to a missing java version in the path variable.

 

This is a new error, that i have not seen so far. I tried to reinstall the container (including deleting the image), as well as going to a backup a couple of days old, I created with the  "Backup/Restore-Appdata" tool.

I could see that the container image was updated on the 3rd of December by ich777, but unfortunaly I do not have a backed up version of the image before this time anymore.

Could it be that the new container image might have a bug? Or did I overlook something else.

 

Thanks and KR

Thomas

 

Edited December 18, 20241 yr by btb205

33 minutes ago, btb205 said:

Hi,

I realized a weird behaviour with the portfolio-performance container today.

The container was installed and automatically updated from the repsective unraid image https://hub.docker.com/r/ich777/portfolio-performance. So far it ran without any problems, but today when starting up, I saw unexpected errors in the VNC session.

 

When I now try to login using the WebGUI, i see an error message, pointing to a missing java version in the path variable.

 

This is a new error, that i have not seen so far. I tried to reinstall the container (including deleting the image), as well as going to a backup a couple of days old, I created with the  "Backup/Restore-Appdata" tool.

I could see that the container image was updated on the 3rd of December by ich777, but unfortunaly I do not have a backed up version of the image before this time anymore.

Could it be that the new container image might have a bug? Or did I overlook something else.

 

Thanks and KR

Thomas

 

Just an FYI, I solved my issue by

- completly deleting the appdata folder for the  container

- reinstalled the container from scratch

 

 

I still do not undertstand what caused the issu in the first place , but after eeting the container complety reinstall itseld and setup the appdata folder from scratch, the issue is gone.

5 minutes ago, btb205 said:

I still do not undertstand what caused the issu in the first place , but after eeting the container complety reinstall itseld and setup the appdata folder from scratch, the issue is gone.

as java is ... lets say very "picky"

 

so may some restart from docker, restart from server, ... may didnt properly close some file in the appdata folder and then ... stuff like this happens on java apps, more common (as more public) in containers like jdownloader ...

2 hours ago, btb205 said:

- completly deleting the appdata folder for the  container

Please don't do that the next time, all you would have needed to do is:

1. Stop the container
2. Remove the jre path from the container
3. Start the container

 

I updated the container to ensure that the container is compatible with the newest PortfolioPerformance version which required a newer version form Java which seamlessly updated for all other people, however it could be the case that your java installation was corrupted (you wouldn't be the first one with such an issue).

53 minutes ago, ich777 said:

Please don't do that the next time, all you would have needed to do is:

1. Stop the container
2. Remove the jre path from the container
3. Start the container

thanks for the hint and the update

 

Quick question though:

where would i remove the jre path form the container?

I could not find it to be defined in the unraid container definition (where I enter the path to appdata, port. etc.), independent if i switched to advanced view or not. I guess a change within the container itself (so login into the container with bash) would not survice the container is rebuild the container from and updated image, right?

 

 

35 minutes ago, btb205 said:

where would i remove the jre path form the container?

Just look into the appdate folder or just read the message.

 

The jre is located in the appdata directory from the container.

2 minutes ago, ich777 said:

Just look into the appdate folder or just read the message.

 

The jre is located in the appdata directory from the container.

sure, makes perfect sense.

When i was checking the appdata folder (before the actual cleanup) i could see the error message was actually right.

There was no /bin/jre... in my /bin folder of the app data. In fact there was no jre folder at all. I found something in the runtime section.
I just could not make a sense how it should have been disappeared from there.

So the idea behin my last question was to figure out, if there is a way to influence at which point the system looks for the jre folder.
In the newly created appdata folder there is no jre folder present as well at this point, but this seem not to be a problem.

31 minutes ago, btb205 said:

So the idea behin my last question was to figure out, if there is a way to influence at which point the system looks for the jre folder.

Nope, that's not possible, the path is fixed to not get users into trouble in the first place.

 

The runtime folder actually contains the jre folder.

34 minutes ago, ich777 said:

Nope, that's not possible, the path is fixed to not get users into trouble in the first place.

 

The runtime folder actually contains the jre folder.

understood.

I looked in an pold backup of the app data folder and could see that the runtime-folder hat actuall 2 jre version, jre17 and jre21. Maybe this caused the problem .

2 minutes ago, btb205 said:

I looked in an pold backup of the app data folder and could see that the runtime-folder hat actuall 2 jre version, jre17 and jre21. Maybe this caused the problem .

Most certainly but the container should remove the jre17 by default and this worked for me and other users.

Really strange that it doesn't worked for you.

i have updated and now I get an error message.

can you tell me what I have to do?

 

1 minute ago, Kono said:

can you tell me what I have to do?

 

may try clearing browser caches, noVNC update ...

2 minutes ago, Kono said:

can you tell me what I have to do?

Please clear the cookies or force a refresh from the website.

 

This is caused because I upgraded the noVNC version from v1.4.0 to v.1.5.0

Thank you very much.

(EE) 
Fatal server error:
(EE) Unrecognized option: -noserverkeymap
(EE) 
---Starting Fluxbox---
---Starting noVNC server---
---Starting ssh daemon---
---Starting luckyBackup---
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, xcb.

/opt/scripts/start-server.sh: line 86:    68 Aborted                 /usr/bin/luckybackup