• Posts

  • Joined

  • Days Won


cybrnook last won the day on May 20 2019

cybrnook had the most liked content!


  • Gender
  • Location
    United States

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

cybrnook's Achievements


Enthusiast (6/14)



  1. Still got some classics from when I first started 🙂
  2. 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.
  3. 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.
  4. This does not look right? Why "I"root and not /root Iroot/.luckyBackup/logs/daily-5am-LastCronLog.log 2>&1
  5. 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.
  6. 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.
  7. @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?
  8. 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.):
  9. 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.
  10. Good! Can you setup a simple backup job to run, say in 5 min and see if it kicks off correctly?
  11. @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.
  12. 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:
  13. 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.