I am not able to get backups running on a schedule. Here's what the crontab says:

User: super user - crontab content
#Initial Cron
#luckybackup entries
O O * * * env DISPLAY=:O /usr/bin/luckybackup --silent --skip-critical /root/.luckyBackup/profiles/
daily-5am.profile > /root/.luckyBackup/logs/daily-5am-LastCronLog.log 2>&1
#end of luckybackup entries

 

Profile is pretty simple:

 

Manual runs work fine. Just no schedule.

Edited December 21, 20232 yr by Mattaton

Trying to setup Luckybackup.

 

Success running command "ssh-keygen -t rsa"

 

Failure running the command that follows, "scp /root/.ssh/id_rsa.pub 192.168.88.80:/root/.ssh/"

 

This is my result:

"kex_exchange_identification: Connection closed by remote host
Connection closed by 192.168.88.80 port 22
lost connection"

On 12/21/2023 at 4:20 PM, Mattaton said:

I am not able to get backups running on a schedule. Here's what the crontab says:

User: super user - crontab content
#Initial Cron
#luckybackup entries
O O * * * env DISPLAY=:O /usr/bin/luckybackup --silent --skip-critical /root/.luckyBackup/profiles/
daily-5am.profile > /root/.luckyBackup/logs/daily-5am-LastCronLog.log 2>&1
#end of luckybackup entries

 

Profile is pretty simple:

 

Manual runs work fine. Just no schedule.

Same with me.  Manuel, no problem.  Schedule not working.

Quick question.  I need to backup some shares that are private, or not shown to SMB at all.  When giving LB "/mnt/user" and root = true, I can only see the shares that are shares.  But if i give LB only "/" then i see all the shares (even hidden ones), but i get a double "/mnt/user/mnt/user/(share name)".  the extra "/mnt/user" is annoying and i don't understand why i cant see all the shares, if my start point is "/mnt/user", since i do have root = true set as well!?!

Maybe I'm not understanding something here??  

I am also having another issue of LB locking up if it doesn't like something (wrong IP address for the remote server for example), then it wont stop/restart the docker container.  It has also seemed to lock while running a local backup, now that im using "/" as the start path.  I haven't tried the remote BU yes since i made the path change.  prior, everything was working great (till i noticed the private shares weren't showing up).

Edited December 29, 20232 yr by miicar
more

On 12/27/2023 at 1:44 PM, Irokiller said:

Same with me.  Manuel, no problem.  Schedule not working.

Hope you get a response.

If this isn't the place to ask such questions, is there a better place to ask them?

On 12/27/2023 at 12:44 PM, Irokiller said:

Same with me.  Manuel, no problem.  Schedule not working.

Make sure you guys have "Console Mode" selected in the Schedule profile...that stumped me for a bit too, but it does work on schedule after i checked that.  Make sure you re-"cronIT !!" after making those changes.  (forgetting that step will also run you around in madness for a couple hours  )

Edited January 1, 20242 yr by miicar

57 minutes ago, miicar said:

Make sure you guys have "Console Mode" selected in the Schedule profile...that stumped me for a bit too, but it does work on schedule after i checked that.  Make sure you re-"cronIT !!" after making those changes.

Thanks. I just turned that on. I'll see what happens tonight.

47 minutes ago, Mattaton said:

Thanks. I just turned that on. I'll see what happens tonight.

Hope that fixes it for you!  You could make a test task and schedule it in an hour or something as a proof of concept as well.

Now if i could only figure out how to make it show ALL the shares, not just the public SMB ones...hmm  Still hoping for a solution to that issue!

Edited January 1, 20242 yr by miicar

On 12/28/2023 at 9:55 PM, miicar said:

Quick question.  I need to backup some shares that are private, or not shown to SMB at all. 
Maybe I'm not understanding something here??  
 

 

Ok.  I think i found the key to my problem.  Like some other dockers i've run into, it hasn't been remapped to recognized multiple cache pools yet!  This is just a guess, but when UNraid got rid of the FUSE layer when the share lives on a cache pool, that strips LB the ability to see it anymore as well.  As soon as i change my secondary storage from none (the requirement for Exclusive Access) to "Array", LB sees the share...weather its hidden, or shared by SMB at all.  Doing this ALSO removes that shares ability to Exclusive Access itself to the network; slowing down some of the r/w operations.  So this is annoying!  I don't feel smart enough to fix it and retain my Exclusive Access settings.  

I hope someone can tell me what i am doing wrong?  Or do is LB not able to see exclusive access shares and I have to go back to writing manual R-Sync scripts for everything?  I want to use my exclusive shares again.

 

 

Edited January 2, 20242 yr by miicar

Just wanted to give a shout out to @ich777 for maintaining this docker, it was JUST what I needed now that I am decommissioning a Synology in exchange for another unRAID box. Was able to get my old data copied over from the Synology to the new backup unRAID system, and then create some stored jobs to keep my main unRAID system in sync again with the already existing data. All in all it went pretty smooth.

 

Also, thanks to @SpencerJ for calling this out and to @spxlabs for the writeup. I used it when wrapping my head around creating remote sources / paths.

I'm in the eastern US, EST timezone. As far as I know, my server time is set correctly, but the cron job in LB is running 6 hours after I have it set for.

I had it set for 5am, and it ran at 11am. I now have it set for midnight and it's running at 6am.

 

Cron jobs via User Sripts plugin run at correct times.

 

Not a huge deal since I can just adjust as needed, but any idea why it's off?

Edited January 4, 20242 yr by Mattaton

12 minutes ago, Mattaton said:

Not a huge deal since I can just adjust as needed, but any idea why it's off?

Probably worth checking how you have the timezone set at the BIOS level as well as the Unraid level.    Not sure what happens if they are different.

13 minutes ago, itimpi said:

Probably worth checking how you have the timezone set at the BIOS level as well as the Unraid level.    Not sure what happens if they are different.

Cool. I'll check the BIOS and see the next time I shut the server down.

Thanks

On 1/4/2024 at 7:36 AM, Mattaton said:

I'm in the eastern US, EST timezone. As far as I know, my server time is set correctly, but the cron job in LB is running 6 hours after I have it set for.

I had it set for 5am, and it ran at 11am. I now have it set for midnight and it's running at 6am.

 

Cron jobs via User Sripts plugin run at correct times.

 

Not a huge deal since I can just adjust as needed, but any idea why it's off?

Just guessing right now (backup server is offline right now), but you'd probably want to do your timezone checking also from within the docker container itself, not necessarily your Unraid server, as the schedule would be from within the container, not your server. And, not sure if you're using the "root" option in the container, but maybe the luckybackup user in the container has a different timezone than root? You could just switch to each user and run the command "date" to see what each user is using.

Edited January 9, 20242 yr by cybrnook

1 hour ago, cybrnook said:

Just guessing right now (backup server is offline right now), but you'd probably want to do your timezone checking also from within the docker container itself, not necessarily your Unraid server, as the schedule would be from within the container, not your server. And, not sure if you're using the "root" option in the container, but maybe the luckybackup user in the container has a different timezone than root? You could just switch to each user and run the command "time" to see what each user is using.

Maybe I'm doing something wrong, but when I go to the terminal for the container and run "time," I just get 0m0.000s. Ran it several times, always says the same thing. Is that supposed to show a clock time?

I am running as root user. ENV var set to true.

 

If I run the date command within the container, I get the correct date and time returned.

Edited January 9, 20242 yr by Mattaton

11 minutes ago, Mattaton said:

Maybe I'm doing something wrong, but when I go to the terminal for the container and run "time," I just get 0m0.000s. Ran it several times, always says the same thing. Is that supposed to show a clock time?

I am running as root user. ENV var set to true.

 

If I run the date command within the container, I get the correct date and time returned.

I was just coming here to say "date" I meant date...... to show the time zone. Had a brain fart.

On my systems I can see that "root" runs as local timezone of the container, but "luckybackup" runs as CET, which is a difference of 6 hours 🙂 So maybe just account for the 6 hour time difference when you make your cron entry. Or, we look for a way to change the timezone persistently for luckybackup user?

 

1 minute ago, cybrnook said:

On my systems I can see that "root" runs as local timezone of the container, but "luckybackup" runs as CET, which is a difference of 6 hours 🙂 So maybe just account for the 6 hour time difference when you make your cron entry. Or, we look for a way to change the timezone persistently for luckybackup user?

 

So, since I'm running as root, do we assume that the cron job is being run by luckybackup user even though the container is set for root permissions to the file system?

 

Well, I guess that's not the case for me, if I run date as root and luckybackup, I still get the same EST output:

root@0e7a9b86e938:/# date
Tue 09 Jan 2024 02:39:12 PM EST
root@0e7a9b86e938:/# su luckybackup
luckybackup@0e7a9b86e938:/$ date
Tue 09 Jan 2024 02:40:27 PM EST

9 minutes ago, Mattaton said:

So, since I'm running as root, do we assume that the cron job is being run by luckybackup user even though the container is set for root permissions to the file system?

 

Well, I guess that's not the case for me, if I run date as root and luckybackup, I still get the same EST output:

root@0e7a9b86e938:/# date
Tue 09 Jan 2024 02:39:12 PM EST
root@0e7a9b86e938:/# su luckybackup
luckybackup@0e7a9b86e938:/$ date
Tue 09 Jan 2024 02:40:27 PM EST

and if you execute "su - luckybackup" from the root user? with the "-". You have to be careful how you switch to different users. Depending on how you do it, you either bring the current user env along for the ride, or have the sytem switch to the new users env. sudo su -, su -, su   all can have different outcomes.

Edited January 9, 20242 yr by cybrnook

5 minutes ago, cybrnook said:

and if you execute "su - luckybackup" ? with the "-". You have to be careful how you switch to different users. Depending on how you do it, you either bring the current user env along for the ride, or have the sytem switch to the new users env. sudo su -, su -, su   all can have different outcomes.

Gotcha. I thought that may have been a problem, but with the "-" it asks for a password and I don't have a luckybackup user set up, so no password.

Is the luckybackup user just there no matter what, even with the root option set to true? If so, is there a default password?

3 minutes ago, Mattaton said:

Gotcha. I thought that may have been a problem, but with the "-" it asks for a password and I don't have a luckybackup user set up, so no password.

Is the luckybackup user just there no matter what, even with the root option set to true? If so, is there a default password?

make sure to pay attention to the spaces I have. So if you're in the container as "root" execute su(space)-(space)luckybackup and see what happens. I assume you probably did something like su- luckybackup or su -luckybackup? Needs to be su - luckybackup

Edited January 9, 20242 yr by cybrnook

1 minute ago, cybrnook said:

make sure to pay attention to the spaces I have. So if you're in the container as "root" execute su(space)-(space)luckbackup and see what happens. I assume you probably did something like su- luckybackup or su -luckbackup? Needs to be su - luckybackup

Okay. I would have sworn I did do the space before and after the dash, but I ran it again and this time it worked. 

Ran the date command, and as you said, it is in CET instead of EST.

So, I guess that's the root of the issue (pardon the pun). And there's no way to update the timezone of the container to match the system, that we know of? At least no persistent way?

Gotta ask the master brain, @ich777, you think there is anyway to have the luckybackup user match the timezone of root, persistently? I was peeking around for a .profile file or .bashrc or something for the luckbackup user, but there is nothing in the home dir. I know docker can be destructive to changes made inside during updates and reboots.

9 minutes ago, cybrnook said:

Gotta ask the master brain, @ich777, you think there is anyway to have the luckybackup user match the timezone of root, persistently? I was peeking around for a .profile file or .bashrc or something for the luckbackup user, but there is nothing in the home dir. I know docker can be destructive to changes made inside during updates and reboots.

Can you describe a bit further what you are trying to achieve?

You can pass over TZ as a variable to the container (which it should do by default), I tested this back with 6.10 I think and it was working fine with the correct timezone.

 

Depends on where you put those files, they should all go into /luckybackup in the container and not in /root (if you are running luckyBackup as root).

5 minutes ago, ich777 said:

Can you describe a bit further what you are trying to achieve?

You can pass over TZ as a variable to the container (which it should do by default), I tested this back with 6.10 I think and it was working fine with the correct timezone.

 

Depends on where you put those files, they should all go into /luckybackup in the container and not in /root (if you are running luckyBackup as root).

I have not experienced this myself as I'm not running scheduled backups, but user @Mattaton is running his system in EST timezone. When he runs a scheulded backup it's exactly 6 hours difference from when he thought it would run. In poking around I can see the "root" user in the container runs as system time zone, but when I switch to "luckybackup" that user runs is CET which is exactly 6 hours time difference. I assume if luckybackup also runs as EST instead of CST then that would fix the problem.

 

I found a basic fix of just creating a .profile file in luckybackup home dir and exporting TZ=America/New_York. That seems to work in my basic testing. You think that should be good enough?

 

Without this, this is what I see:

Edited January 9, 20242 yr by cybrnook