cybrnook

Still got some classics from when I first started 🙂

Just want to throw out that I have tested with and without "root" mode, and when I schedule my cron I have tested with and without "console" mode. Both options are working for me with the .profile workaround. I just tested at 4:25 PM EST (which is 16:25 in LuckyBackup) and it worked fine, nonroot and not in console mode: Make sure you're not doing something silly when making the schedule like forgetting that lucky is a 24 hour clock and not a 12 hour clock. So, 5:00 PM for example is 17:00.

Then at this point I'd say let's wait and see what @ich777 comes back with. From my side it seems to be working, and it worked for you yesterday, so I am unsure at this point if there is something else that we are missing.

This does not look right? Why "I"root and not /root Iroot/.luckyBackup/logs/daily-5am-LastCronLog.log 2>&1

I think it looks fine. I just did a simple test of running all my backup jobs here in EST and it worked fine for me. @ 11:22 EST my cron'd backup job kicked off without issue.

Create another job in there to run in just a couple minutes, see if that works. Would verify if we're close to something or not.

@Mattaton when you ran the 5 minute test yesterday, where it worked, was that a newly schedule job? I am wondering if you need to perhaps remove and recreate the cron entries now that you made the TZ change?

@Mattaton let's continue in the support thread.

Schlaf gut 🙂 (Sleep well)

That didn't work (just to calrify, the "root" user in the container is fine, it's the "luckybackup" user that is running as CET. That seems the be the main app user within the container, where cron is being used.):

Yes, I think so. That's where @ich777 has been pointing all users to go for persistent changes (like keys). This should be no different.

Good! Can you setup a simple backup job to run, say in 5 min and see if it kicks off correctly?

@Mattaton Try and and see if it works Log into docker console (you will be root), and execute: su - luckybackup touch .profile echo "export TZ=America/New_York" > .profile Then restart your container and check the "date" commands again. Then maybe test a simple scheulded backup and see if it kicks off when you want it to.

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:

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.

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

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.

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?

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

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.

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 was able to work around my issue by doing 2 x things, not sure which one was it. But first I tried in Firefox, which had no sessions cookies already, so was a fresh login. When I went to Replace Key, I had to log into my unraid account and give a fresh 2 factor code. After logging in here, I was able to see both ID's and everything went smooth from there.

Also having the same issue, opening a support ticket now. EDIT: Marked ticket as resolved

Yep, this also did the trick (blacklisting ast). Let me boot into unraid while still using the onboard VGA, no external GPU required.

@Lixx3r @trurl @JorgeB I've been fighting this same issue for a few days now, pulling out what little bit of hair I have left. But in my case I was able to work around it. In my case, I am doing a new Unraid build, getting ready for the 6.13 BETA to start as I want to do a massive all flash array on ZFS with bifurcated cards and ssds, so I'm building a new Threadripper based system with a 5955WX and currently an AsRock Rack WRX80D8-2T board (though I have tested a few boards with the same issue lately). Come to find out, all the boards I have been testing with have an onboard BMC/IPMI interface with the AST2500 built in VGA. I had to plug in a standalone VGA as my VGA to HDMI adapter was seemingly not working and I needed to see what post was telling me. While display was correctly routing through my GTX 1030 until unraid started loading the drivers for the BMC. Soon after it seemed to "freeze" at "AES CTR mode by8 optimization enabled". What I am thinking may be happening is unraid loads the drivers for the onboard BMC and then routes output to that, leaving the session I am watching stale, as if the system froze. I ended up disabling onboard VGA in the bios, and what do you know, booting without issue. Just wanted to chime in for someone else having a similar issue.