21 hours ago, Stannis33 said:

So I rebooted my server, changed the container name back to sonarr......and it stopped again.

That is really weird! 😮

 

21 hours ago, Stannis33 said:

When you  say the container logs do you mean the sonarr logs or some actual docker logs?

Container logs.

 

21 hours ago, Stannis33 said:

The sonarr logs say nothing, even in debug mode, they just stop logging

Weird.

 

21 hours ago, Stannis33 said:

Where might I find the "meta infos"?

docker inspect sonarr (or sonarr2). That gives some unraid labels in between back, but nothing special:

                "net.unraid.docker.icon": "https://guacamole.apache.org/images/guacamole-logo-64.png",
                "net.unraid.docker.managed": "dockerman"

I dont get, what is causing your container to stop. Something within the Unraid logging window at the time? Or maybe something inside /var/log/docker.log?

 

21 hours ago, Stannis33 said:

It seems I do.....it is set to run at 02:47

Hmm. Should not caused that error. The Container AutoUpdate is not needed anymore with the new appdata.backup btw. There is an auto update feature built in.

 

11 hours ago, Thx And Bye said:

The error occurs on manual backups too

Thats weird, too. Somehing inside Unraid logging windows and/or /var/log/docker.log at this time?

Could you post the results of "docker ps -a"? and maybe "docker image inspect *your Jd image name*". Replace the image name with the exact image name with tag! You can first list all valid image ids with "docker image ls -a".

Weird is definitely the word to use!

 

Ok so I have:
docker inspect for the container while named sonarr (while running)

https://pastebin.com/KLA32xvc

 

docker inspect for the container while named sonarr2
https://pastebin.com/9hJ2UgrT

 

And this is what appeared in the system log for the rename (from sonarr2 to sonarr) and subsequent stop

https://pastebin.com/ywgRKBS9

 

 

2 hours ago, KluthR said:

Or maybe something inside /var/log/docker.log?

Ummm.......I don't seem to have that. At least I can't find it, but I didn't build the server so I don't really know where anything is. Where should I be looking for that? Or is it possible that docker has been set to not log? I couldn't find any kind of option for that but I may have been in the wrong place😕 

Never mind, I hadn't Googled hard enough 
Docker logs:
https://pastebin.com/56MdDy2Z

Edited April 14, 20233 yr by Stannis33
update

19 hours ago, Stannis33 said:

docker inspect for the container while named sonarr (while running)

https://pastebin.com/KLA32xvc

 

docker inspect for the container while named sonarr2
https://pastebin.com/9hJ2UgrT

Looking good. Nothing obvious inside a diff.

 

Maybe this is one for the docker section. Im out

5 minutes ago, KluthR said:

Maybe this is one for the docker section

Thanks for trying

Do have a suggestion for a specific thread to ask? I tried General Support but got no reply......

That section should be ok.

 

Could you try this: Open a terminal, enter "docker system events" this starts a real-time docker event output. Start sonarr (which is failing) and let it crash. docker should output some lines, ioncluding "container die". Please post that here along with a "docker logs sonarr".

2 hours ago, KluthR said:

Could you try this: Open a terminal, enter "docker system events" this starts a real-time docker event output. Start sonarr (which is failing) and let it crash. docker should output some lines, ioncluding "container die". Please post that here along with a "docker logs sonarr".

 

system events:
https://pastebin.com/ZCJ2xphJ

 

sonarr logs:
https://pastebin.com/FvBf8r9E

sonarr is dying with exitCode=0 which should be a normal stop, initiated by the container. Stopping some of my test containers show the same beavior. Let one of my test sql start with wrong volumes/corrupt data, ends up in another exitCode.

 

I still dont see, what is failing just because of a name change

@KluthR just thought you might like to know, since you spent so long trying to help me, that my weird "sonarr" issue *might* finally have been identified

It seems there was an rclone related user script which looks like it was supposed to stop and start the containers and involved a dropbox and other credentials which aren't mine. Theory being these credentials are no longer valid and so things were failing somewhere. Looks like it stopped the container but never got round to starting it again

That script was set to run every 10 minutes.....hence the max run I ever got was 10 minutes and usually only around 5.

With the script disabled, my "sonarr" container has now been running for 2 hours. I am a little reluctant to actually believe it.....but maybe....just maybe.....

My appdata share keeps changing owner from nobody to unknown when appdata backup runs. Any ideas what’s happening and what steps I may need to do to fix it?

Hello from Austria,

i use this tool 2nd time but always get this errors:

 

[18.04.2023 06:11:40] Backing Up: docker.img
/usr/bin/tar: docker.img: file changed as we read it
[18.04.2023 06:15:17] tar creation/extraction failed!
[18.04.2023 06:15:17] Verifying Backup docker.img
docker.img: Mod time differs
docker.img: Contents differ
[18.04.2023 06:18:59] tar verify failed!

How could I fix this?

 

Thanx,

faxxe

 

7 hours ago, Macj72x said:

My appdata share keeps changing owner from nobody to unknown when appdata backup runs.

The plugin does not change any ownerships. I just checked my dev environmemt and all id as it should be. Docker is managing access rights on mappings.

 

what does „unknown“ mean? A number? Like 999? If yes, thats normal.

 

7 hours ago, Stannis33 said:

It seems there was an rclone related user script which looks like it was supposed to stop and start the containers

Sounds like an suitable candidate 😂

 

2 hours ago, faxxe71 said:

i use this tool 2nd time but always get this errors:

check your ca.backup2 source config: you are backing up the wrong paths (or your docker.img is inside your appdata). Both cases are unfavorable

 

 

 

EDIT: somehow we seem to mix posts for ca.backup2 and appdata.backup….

 

so: for old ca.backup2: Macj72x: the old plugin should not change ownerships as well.

Edited April 18, 20233 yr by KluthR

1 hour ago, KluthR said:

check your ca.backup2 source config: you are backing up the wrong paths (or your docker.img is inside your appdata). Both cases are unfavorable

 

 

Hello,

you are right. All my dockers are in the folder /dockers installed and the docker.img as well

To me, this /appdata logic seemed a bit illogical and unfamiliar at the beginning with Unraid. Therefore, this way.

 

Can i change the path in the app or should i change my whole way of docker installation?

 

-faxxe

 

You can stop docker service, move the img to its default path and start it again. Then stop all containers, move all appdata, adapt every container path mapping and you should good to go*.
 

* No warranty

 

For further question, you should ask inside the docker section.

In the image blow is the error im getting. I am having a brain fart and dont know where the logs are store for this plug in. Please let me know so I can get those uploaded as well.

 

5 minutes ago, Jurak said:

I am having a brain fart and dont know where the logs are store for this plug in.

Just click the status tab.

36 minutes ago, wgstarks said:

Just click the status tab.

I was thinking of a place to download the file but yeah that works to lol.

CA Backup Logs.txt

3 hours ago, Jurak said:

In the image blow is the error im getting.

Exactly what it states: Something is accessing mentioned paths during backup/verification though plex is stopped.

any 3rd party script/plugin which is working with Plex‘ container? It also was stopped 3 mins before the backup.

58 minutes ago, KluthR said:

Exactly what it states: Something is accessing mentioned paths during backup/verification though plex is stopped.

any 3rd party script/plugin which is working with Plex‘ container? It also was stopped 3 mins before the backup.

Just doubled checked I have no scripts that will run for plex. Only scripts I have are for the data on the array.

1 hour ago, Jurak said:

Just doubled checked I have no scripts that will run for plex. Only scripts I have are for the data on the array.

What about other apps/dockers?

2 hours ago, wgstarks said:

What about other apps/dockers?

Thats the thing all dockers are supposed to be shut down and backed up but this log only has plex being shut down.l

4 hours ago, Jurak said:

but this log only has plex being shut down

Since Plex was already down, someone/something has done it before.

Ok this time it ran with out errors. So why in the last logs did it only do plex and this time it did everything. I made no changes in the settings.

ca backup logs 2.txt

22 minutes ago, Jurak said:

Ok this time it ran with out errors. So why in the last logs did it only do plex and this time it did everything. I made no changes in the settings.

ca backup logs 2.txt 30.19 kB · 0 downloads

Last time there was some change to the Plex data while the backup was in progress. This time that didn’t happen.

On 4/14/2023 at 7:49 PM, KluthR said:

Thats weird, too. Somehing inside Unraid logging windows and/or /var/log/docker.log at this time?

Could you post the results of "docker ps -a"? and maybe "docker image inspect *your Jd image name*". Replace the image name with the exact image name with tag! You can first list all valid image ids with "docker image ls -a".

 

The output from docker ps -a.txtlooks rather normal to me.

Here is the docker inspect 2eda680bcc88.txt but I can't see anything special about it either?

 

Here is the log of the containers starting:container startup logs.txt

I just uninstalled the deprecated plugin and copied the paths over to KluthR's plugin. I get the below message in red and it is not clear to me what I can do to configure the plugin any differently to resolve this.

 

"Note: You should specify a backup share (and subfolders) dedicated to that particular backup. It is entirely possible for backups to erase any other files contained within the destinations."

iss-diagnostics-20230421-1019.zip