Overview: Support for Docker image arch-urbackup in the binhex repo.

Application: UrBackup - https://www.urbackup.org/

Docker Hub: https://hub.docker.com/r/binhex/arch-urbackup/

GitHub: https://github.com/binhex/arch-urbackup

Documentation: https://github.com/binhex/documentation

 

If you appreciate my work, then please consider buying me a beer 

 

 

For other Docker support threads and requests, news and Docker template support for the binhex repository please use the "General" thread here

Edited July 31, 20195 yr by binhex

Hi, when i start the Container i brings and Error and not Starting.

 

2019-07-30 18:42:58,027 DEBG 'urbackup' stdout output:
2019-07-30 18:42:58: ERROR: Running as wrong user. Specified user "urbackup" with uid 976 but running as uid 99

10 minutes ago, DrAg0n141 said:

Hi, when i start the Container i brings and Error and not Starting.

 

2019-07-30 18:42:58,027 DEBG 'urbackup' stdout output:
2019-07-30 18:42:58: ERROR: Running as wrong user. Specified user "urbackup" with uid 976 but running as uid 99

gremlins :-), im just beating them with a hammer right now, will have a gremlin free version shortly.

This looks like a great tool. Excited to try it out once those gremlins are gone 🔨

2 hours ago, secondsunrise said:

This looks like a great tool. Excited to try it out once those gremlins are gone 🔨

the gremlins are now gone, but i have had to tweak the networking over to 'host', so please pull down the latest image and then switch from 'bridge' over to 'host' for the container, i got it currently doing a system level backup of my laptop, going nicely!.

interested to see how you guys are getting on with urbackup?, anybody attempted a bare metal recovery yet?

I'm a noob at dockers so if anyone else struggles with this error, I had to go into the Settings tab and change the "Backup storage path:" to /media

I am having trouble using this docker. I have tried the default settings, changed to a custom IP and to a bridge. The docker runs but I can not access the ui. I have also tried changing the PUID and PGID to root user. Any suggestions? Windows client doesn't see the server either.

ur docker log.txt

2019-07-31 23:47:51,150 DEBG fd 8 closed, stopped monitoring <POutputDispatcher at 23340731759920 for <Subprocess at 23340731666104 with name urbackup in state STARTING> (stdout)>
2019-07-31 23:47:51,151 DEBG fd 10 closed, stopped monitoring <POutputDispatcher at 23340731666384 for <Subprocess at 23340731666104 with name urbackup in state STARTING> (stderr)>
2019-07-31 23:47:51,152 INFO exited: urbackup (exit status 132; not expected)
2019-07-31 23:47:51,153 DEBG received SIGCHLD indicating a child quit
2019-07-31 23:47:54,161 INFO spawned: 'urbackup' with pid 69
2019-07-31 23:47:54,214 DEBG fd 8 closed, stopped monitoring <POutputDispatcher at 23340731801784 for <Subprocess at 23340731666104 with name urbackup in state STARTING> (stdout)>
2019-07-31 23:47:54,215 DEBG 'urbackup' stderr output:
/home/nobody/start.sh: line 15: 74 Illegal instruction /usr/bin/urbackupsrv run --config /config/urbackup/config/urbackupsrv --no-consoletime

This is what I get when starting the container. Any ideas?

1 hour ago, germericanish said:

2019-07-31 23:47:51,150 DEBG fd 8 closed, stopped monitoring <POutputDispatcher at 23340731759920 for <Subprocess at 23340731666104 with name urbackup in state STARTING> (stdout)>
2019-07-31 23:47:51,151 DEBG fd 10 closed, stopped monitoring <POutputDispatcher at 23340731666384 for <Subprocess at 23340731666104 with name urbackup in state STARTING> (stderr)>
2019-07-31 23:47:51,152 INFO exited: urbackup (exit status 132; not expected)
2019-07-31 23:47:51,153 DEBG received SIGCHLD indicating a child quit
2019-07-31 23:47:54,161 INFO spawned: 'urbackup' with pid 69
2019-07-31 23:47:54,214 DEBG fd 8 closed, stopped monitoring <POutputDispatcher at 23340731801784 for <Subprocess at 23340731666104 with name urbackup in state STARTING> (stdout)>
2019-07-31 23:47:54,215 DEBG 'urbackup' stderr output:
/home/nobody/start.sh: line 15: 74 Illegal instruction /usr/bin/urbackupsrv run --config /config/urbackup/config/urbackupsrv --no-consoletime

This is what I get when starting the container. Any ideas?

I'm seeing the same thing here. Haven't had a chance to do much playing around to see if I can find a fix yet, but about to do that now.

I'm a noob at dockers so if anyone else struggles with this error, I had to go into the Settings tab and change the "Backup storage path:" to /media

It looks like a hardcoded default, I've found no way of changing it, so you have to do this as step 1

Sent from my CLT-L09 using Tapatalk

8 hours ago, phreeq said:

I'm seeing the same thing here. Haven't had a chance to do much playing around to see if I can find a fix yet, but about to do that now.

2019-07-31 08:07:58,322 DEBG fd 8 closed, stopped monitoring <POutputDispatcher at 22830330100704 for <Subprocess at 22830330192056 with name urbackup in state STARTING> (stdout)>
2019-07-31 08:07:58,323 DEBG fd 10 closed, stopped monitoring <POutputDispatcher at 22830330191944 for <Subprocess at 22830330192056 with name urbackup in state STARTING> (stderr)>
2019-07-31 08:07:58,323 INFO exited: urbackup (exit status 132; not expected)
2019-07-31 08:07:58,323 DEBG received SIGCHLD indicating a child quit
2019-07-31 08:07:59,326 INFO spawned: 'urbackup' with pid 48
2019-07-31 08:07:59,353 DEBG 'urbackup' stderr output:
/home/nobody/start.sh: line 15: 53 Illegal instruction /usr/bin/urbackupsrv run --config /config/urbackup/config/urbackupsrv --no-consoletime
 

 

My error log also, the same.

2 hours ago, ngreis said:

/home/nobody/start.sh: line 15: 53 Illegal instruction /usr/bin/urbackupsrv run --config /config/urbackup/config/urbackupsrv --no-consoletime
 

 

My error log also, the same.

im going to take a look at this shortly, strange that it starts ok for me and @secondsunrise

@ngreis @germericanish @phreeq @dstark4 ok ive just tried a brand new config and it starts up with no issues for me. so i can only assume the issues are related to the early bugs in the image, can you all please stop the container, then delete all files and folders located in your host defined /config folder (probably /mnt/user/appdata/binhex-urbackup) then start the container again.

 

please ensure 'Network Type' is set to 'Host' it should NOT be set to anything other than this.

I deleted the image from appdata, and re-downloaded the docker and left everything default with the exception of pointing /Media to an empty share. Still having the same problem. I have attached a screenshot of the config.

ur docker log.txt

29 minutes ago, dstark4 said:

Still having the same problem. I have attached a screenshot of the config.

hmm ok so i can see the issue, for some reason it is not creating the folder 'binhex-urbackup' in '/mnt/user/appdata/' and thus the error when we attempt to start urbackupsrv, as its pointing at /config.

 

so i can only put this down to permissions issues, can you please ssh to the host and issue the following command and paste the result here:-

ls -al /mnt/user/appdata/

 

Sorry, I should have specified that the screenshot was from after deleting the folder from appdata, but before reinstalling the image. The folder was created when I hit apply. I did however go ahead and run the command.

~# ls -al /mnt/user/appdata/
total 16
drwxrwxrwx 1 nobody users  202 Aug  1 10:06 ./
drwxrwxrwx 1 nobody users   52 Jul 31 15:16 ../
drwxrwxrwx 1 nobody users   62 Dec  1  2018 MakeMKV/
drwxrwxrwx 1 nobody users   20 Dec  1  2018 PlexMediaServer/
drwxrwxrwx 1 nobody users   12 Dec 13  2018 QDirStat/
drwxrwxrwx 1 root   root    22 Jul 28 13:28 Shinobi/
drwxrwxrwx 1 nobody users   96 Dec 31  2018 Sync/
drwxrwxrwx 1 nobody users   96 Dec 31  2018 SyncWan/
drwxrwxr-x 1 nobody users   64 Aug  1 10:02 binhex-krusader/
drwxrwxr-x 1 nobody users   64 Aug  1 10:07 binhex-urbackup/
drwxrwxrwx 1 nobody users   80 Jun 26 23:27 clamav/
drwxrwxrwx 1 nobody users   44 Jul 19 20:44 grocy/
drwxrwxrwx 1    999 users 6642 Jul 31 15:29 mongodb/
drwxrwxrwx 1 nobody users  110 Dec  1  2018 unifi/

 

3 minutes ago, dstark4 said:

Sorry, I should have specified that the screenshot was from after deleting the folder from appdata, but before reinstalling the image. The folder was created when I hit apply. I did however go ahead and run the command.

ahh right :-), that makes more sense, and from your bottom screenshot, inside the folder 'urbackup' there are files and folders in there right?

4 minutes ago, binhex said:

ahh right :-), that makes more sense, and from your bottom screenshot, inside the folder 'urbackup' there are files and folders in there right?

Correct, there are folders however of the four folders within the folder only the config folder has anything and it is one file. The urbackupsrv. Would I be correct in assuming that there should be more files?

Edited August 1, 20195 yr by dstark4
add attachment

1 minute ago, dstark4 said:

Correct, there are folders however of the four folders within the folder only the config folder has anything and it is one file. The urbackupsrv. Would I be correct in assuming that there should be more files?

yes it should look something like this, are you running unraid 6.7.x by any chance?:-

 

Yes, 6.7.0. Hadn't moved to newest version as I haven't had any problems. Will upgrade to 6.7.2 and retry just in case.

1 minute ago, dstark4 said:

Yes, 6.7.0. Hadn't moved to newest version as I haven't had any problems. Will upgrade to 6.7.2 and retry just in case.

so one of the issues with 6.7.0 through to 6.7.2 is sqlite database corruption, im not sure if you are aware of this issue or not but it can affect certain applications which make use of sqlite, this application does indeed make heavy use of sqlite so this might be the issue.

 

so there is currently no fix for 6.7.0 or later of unraid, but you can reduce the chance of this happening by switching to the disk share as opposed to the fuse, so to do this stop the container and then change the path for /config to /mnt/cache/appdata/binhex-urbackup and then apply - NOTE this only can be changed to this if you have a cache drive, if you dont have cache drive then change the path to /mnt/disk1/appdata/binhex-urbackup

Updated, Reinstalled the docker with config pointed to cache. Still have the same problem of the appdata missing the majority of files.

 

If this caused by the sqlite bug, I can wait until the limetech team has a fix. Thanks for the help

18 minutes ago, dstark4 said:

If this caused by the sqlite bug, I can wait until the limetech team has a fix. Thanks for the help

i can only assume the sqlite bug is the cause, as i cannot replicate what you are seeing on my machine, of note is the sqlite bug strangely only affects certain machines, some people have the issue, others do not, im one of the lucky ones, hopefully LT will squash the bug once and for all in the next release.

Edited August 1, 20195 yr by binhex

Hello

 

Did all of the above things in the thread, issue still the same.

Running 6.7.0 also.

Will also wait for a fix for that bug.

 

Best regards

Nuno Reis