Mattaton

Kinda confusing, isn't it? 😄 I've found the only way to know for sure when it ran is to look at the modified date/time on the log file. Not the date/time in the file content, but the modified date/time of the file itself. I don't know much about container development, but I think this stuff is largely out of @ich777 hands and comes down to how LuckyBackup handles the timezone fed to it by the container (or by the host system if it was run in a typical OS scenario). Seems like it sorta honors it, but in many ways it drops it or misinterprets/translates it. I'm just glad I can get the CRON tasks to run when I set them to without having to translate the time (in my case, subtract 6 hours) I set the CRON to run just to get it to run when I want. It used to be that way, but this time it is letting me use my local time and it's working. As long as it's running at the correct time, I guess it doesn't really matter. Just a little math and timezone translation to do if you need to look at logs, or the LB interface for that matter. It's annoying at most. Mostly it's just a set-it-and-forget-it thing. Just check every once in a while to make sure it's still working. I also went ahead and set up email if it hits an error. Good to know I am not alone in the confusion, though. 🙂

So there's still some timezone issue with LuckyBackup. It definitely wants to live in CET/CEST and has a lot of holes in timezone translation. CRON has my profile run at the correct time according to the modified time on the log files (6am EDT). But LuckyBackup interface says it ran in the future +6 hours at 12 noon today (It's currently 9:45am EDT). Interface says 12:02:47 PM EDT, the logs also say that time, but with CEST timezone (which is technically correct). What makes things more interesting is that if I run the profile manually, the interface shows the accurate time EDT. So the interface shows the incorrect time only when CRON triggers the profile. Not sure what the log files will show as the logs for individual tasks have not a single mention of the date and time it ran (which I find odd). Accurate when triggered manually: Not sure if there's anything that can be done about this. The backups are working and running when I want them to, so this is a minor annoyance. This is certainly better than the 6 hour offset I had back in January where I had to subtract 6 hours on the CRON time to get it to run when I actually wanted.

Gotcha. Yeah, it just wasn't working back in January. Had to add that .profile file to the root of the config folder with the TZ setting in it to get it to work back then. It's working with this new cron setup, but I don't know which of the two "solutions" is making it work this time. 🙂

Yeah, that's something I realized back in January when testing timezone offset issues. I thought it wasn't running until I restarted the container and it updated. Now I just watch the log files instead to see if they update. 🙂 I thought I would have the timezone problems I had before. It always ran on CET/CEST even though I had it set to EST/EDT. So I had to subtract 6 hours from the cron time to get it to run when I actually wanted it to. But setting it up this time, it seems to run properly at the configured time EDT. I don't know if it's the TZ setting in the container finally working, or if it's still the .profile file @cybrnook helped me create. But it seems to be working this time around. (Pardon the pun.) I wish the log file content adjusted to work with the configured TZ setting. But subtracting 6 hours is pretty easy to do. Even I can do that. 😄

Much appreciated. And as soon as I saw the Console Mode thing I had an, "Ah that's right!" moment. Just been a minute since I have tinkered with LB and wasn't dotting all the I's and crossing all the T's like I did the first time. Too focused on finding old problems. 🙂 Thanks for putting up with folks like me. 😄

<sheepish> I had just clicked the edit button on my post to say "Console Mode." 😕 Dude, there are so many things to read. I was looking for my old timezone offset problems. Wasn't even thinking about that. 😄 Good news is, it seems to run at the correct time without the timezone problem. Sweet! Thanks!

LuckyBackup - Trying to get cron to work and see if my problems from back in January with the timezone offset is still an issue. I tried to trigger a job to run in 2 minutes and nothing seemed to happen. Went looking in the logs and found that the LastCronLog.log file for the profile had been updated at the time the job was supposed to run. It says: No protocol specified qt.qpa.xcb: could not connect to display :0 qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found. This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem. Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, xcb. Aborted Any idea how I fix this? Thanks!

Absolutely. Sorry. I just realized this when looking back through the thread for that old conversation when @cybrnook replied to tell me to continue the discussion in the support thread. 🙂 Apologies for starting this topic here as well. I just searched for LuckyBackup in the forum and this one popped up and seemed familiar. Feel free to delete all this to keep this thread clean.

Yep. That's how it's been for me. I think the destination side only ended up with the UNKNOWN after the source had been changed and then another sync operation ran which updated the destination with the UNKNOWN owner. In my testing over the last few days, only the source side was changing. Complete side note again - remember back when we were trying to get the cron job to run at a certain time and it was 6 hours or so off when it ran, even though the cron text looked correct? I wanted it to run at 5am and I would have to set it at 11pm to get that to happen. Another user (I forget the name offhand) was having the same problem and added a file to the config to alter the timezone or something. But you said you didn't like that way of doing it and wanted to devise another way. Did that ever go anywhere or should I still offset the scheduled time? THANKS!

Gotcha. I think you were replying while I was editing my reply with my "oh wait, I see what you're saying... 😄 I'm on the same page with you now! This answers so many questions as to why my script to backup and keep only 14 backups wasn't working. As soon as the sync ran, it copied all the "backups" from the destination back to the source. Ugh. I was trying to treat sync like a mirror. Sync the source to the destination, but not thinking about it syncing the destination back to the source. I think it was the terms source and destination that got me. Seems one-directional. I just ran a test, and of course, if it's now only pulling from the source it doesn't have to change anything. Still though, and a total sidenote as you have me sorted: If someone did want to use sync, why would the owner get changed on the source side? THANKS!!!

Okay? But isn't sync a viable option if I want the destination to have on it exactly what the source has on it? So if a file is removed from the source, I also want it to be removed from the destination. Is a sync not the way to do that? Basically, I want a duplicate of the backup on the source on the destination. Wait, I see what you mean. If I were to add a file onto the destination, it would copy it onto the source. BAD. I don't monkey with the destination, so this has not been an issue. But I can see how it could be. I assume you aren't saying this is the reason that the owner is changing, right? Like, if someone were to use sync (and mean to) the owner shouldn't change on the "source" side, right?

Okay. I've attached the profile for these tasks. @Kilrah I wanted to point out, I have this issue on all folders that LuckyBackup backs up. Not just the ones that db-backup also has access to. For example, my Vaultwarden backup folder is not touched by db-backup, but when I sync that folder to the remote server with LB, the Vaultwarden folder and all folders within are changed to owner UNKNOWN (including the .luckybackup-snaphots folder that LB controls). See images below (before/after LB run). Does this same thing on all folders that LB syncs, including my Immich folder (which is the live folder used by the immich container and not a backup that is just synced to the other server). I can make the volume read-only to LB, but if I do that, it can't write to the .luckybackup-snaphots folder. daily.profile

I'll post screenshots of my LB settings when I get back to my PC. The screenshots I posted previously are of the source. It's in the backup folder because that's where the database backups are stored. Then LB syncs the backups to another server. So, even though it says it's in the backup folder, it's the source folder for LB.

Hello again, @Kilrah 😊 Can you elaborate on what I need to look at? Adding the user ID and group ID vars to db backup was the fix there, but Lucky Backup already has vars for that. I agree with you and @ich777 that this is a problem on my end and not with Lucky Backup. I am grateful for whatever insight you can provide. Thanks!!!

Yeah, I ended up with multiple instances, too. I seem to remember running into problems trying to get multiple jobs running out of one container (but I could have been doing something wrong). Multiple container instances works fine, so probably no need to switch. 🙂 I especially remember having problems getting postgreSQL backups to run at all. I forget the errors it was throwing in the logs, but finally got it working. When I first started using the container via CA, it was lacking tons of vars compared to the updated container on github. Glad to see it's been updated to include some of them accurately.

Sorry to keep bothering you, @ich777 I got the db-backup container working correctly. I tested and it was doing the owner switch on my home and work servers. So it wasn't a server specific issue. Turns out it had missing user and group variables I could add into the template. Now it works correctly and doesn't change the owner when it runs. So I'm down to only luckBackup doing this. Is there something in the luckyBackup task setups that could cause this? It's been a while since I set them up, but I thought I did it per your recommendations/instructions. Kinda scratching my head on this one. I don't want to have to drop back to rsync scripts or research something like borgmatic. 😕

YES! Thank you!!! Yeah, I had gone through the docs pretty extensively and added/changed lots of variables. I had missed the USER_DBBACKUP and GROUP_DBBACKUP though. I'm not sure if the more recent versions of the unRAID template have all these updated vars or not. When I first set it up, it was missing a lot. Where you've used DEFAULT_, I assume this is working for you? I had added these same vars but with the DB01_ prefix that it seemed like was needed per mySQL, postgreSQL, etc. But then I couldn't get it to do more than one database type for one db-backup container. So I had to abandon the DB01, DB02 approach and set up multiple container instances. This works, but maybe using DEFAULT_ is the better way to do it.

db-backup container question: Is there some reason that each time a backup runs, it changes owner on the backup folder and files to UNKNOWN? This initially caused permission issues when I tried to then sync the backups to another server, but I added the vars DB01_FILESYSTEM_PATH_PERMISSION and DB01_FILESYSTEM_PERMISSION and set them to 777 to get around this. Is it possible to add PUID and PGID to this template? I'm not sure exactly how all that works since I've never built a container template before. I have set up a user script to chown things back to 'nobody' after each run. An obvious band-aid on the problem. I posted an issue on the db-backup github, but they ignored and closed it since it's an unRAID template and not a direct use of their container. 😕 Thanks! P.S.: Last I checked, the template needs several updates to match the ENV vars from the container. I had to add/change a bunch of them to match the github repo.

Yes, sir. You do the same, Peter. 🙂

If you click the name of a VM, that info will show beneath it. Click the name again and it will hide the info. As @scolcipitato said, this is just what vanilla unRAID does. Not a feature added by FolderView plugin. EDIT: I see @SimonF already explained how clicking the VM name works. 🙂

Okay. I did a test and running the LB task is changing the owner on at least one folder and I can reproduce the outcome every time. With the host folder set to read-only, I get errors in the log. I assume because it wants to write the .luckybackup-snaphots (incidentally, those folders are misspelled. Missing the S in shots 🙂 ) folder to the source? Not a big deal as long as it backs up. So, just for testing, I switched the host directory back to read/write. I set owner:nobody on the entire folder to be backed up. I run LB backup task and come back and the files have the correct user, but all the folders keep being switched to UNKNOWN every time I run the task. But, it does not set the owner to UNKNOWN on the destination (maybe because all the files are already synced and it has nothing to write to the destination). I posted a separate thread on the unRAID forum to see if I can get somebody that knows more to give me some insight as to why this could be happening. I don't think it's just a LB thing. Obviously the db-backup container is doing it too. Before LB run: After:

I've been trying to track down an issue where certain folders and files are having the owner changed to UNKOWN. I first noticed the issue when using the tiredofit db-backup container to backup my mariadb Databases. I was then trying to sync those backups to another server and I was getting permissions issues. Looking into this, I am able to set the permissions from within db-backup, but not PUID and PGID. So, I can manually set everything in the backup folder to owner: nobody, but as soon as a backup runs, all folders are set to UNKNOWN. This hasn't been a huge issue since I could set the permissions to still allow the sync to run even if the owner wasn't what I'd like. The next time I saw the issue was with Immich. I was getting intermittent permission errors in the logs when trying to auto-upload a photo. When I went to look in the Immich folders, the owner was set to UNKNOWN. Immich has the PUID and PGID set to 99 and 100. And when Immich creates a folder or file, it is set to nobody as would be expected. But I have a container luckyBackup that syncs the Immich photos to another server. It would seem that each time this job ran, it changed the owner to UNKNOWN (I have yet to fully investigate luckyBackup as being the culprit - but it was disabled last night when it would normally have run a backup and the owner is still set correctly to nobody this morning). So, being that I am a novice, what would you unRAID gurus do next to investigate what is causing this? I have db-backup that seems to be doing this (and I can replicate the issue readily), but it has no access to Immich. So it can't be causing the problem there. Then I have luckyBackup. The folders is pulls from and backs up to all come out set to UNKNOWN. It was also syncing the DB backups, so I thought it was causing it everywhere until I ran the db-backup and realized it was doing it to the database backups on its own. Is there some overall server setting that could be causing this? PUID and PGID seems to work fine 95% of the places they're set in containers. So it doesn't seem like the IDs are messed up. I'm grasping at straws here. 🙂 Thanks!

I really have no idea if something is misconfigured or what that might be. Most things seem to be fine. Owner isn't being randomly changed by the owning containers. For instance, if images upload to immich, the folders and images have the correct owner/permissions. BUT...I did just run the tiredofit db-backup container that backs up my mariadb dbs. I watched the folder where it backs up to. All files and folders were set to nobody, then it ran and all files and folders were set to UNKOWN. But not in the Immich folder. The db-backup container has no access to the Immich folder. So that's not what is causing the owner to change there. But it does speak to some sort of issue somewhere that is unrelated to LB. But what? If other containers aren't changing owner settings, it can't be an issue across the board. Immich also uses 99 and 100, but the owner stays nobody. So it's not something like the user IDs on my machine are fouled up. Here's my LB container settings (I will at the least take your advice to set the host files to read-only):

@ich777 I just noticed this in the template settings for the luckyBackup container: Shouldn't these vars be PUID and PGID? All other containers I've ever used, these vars have the P in front. Could that maybe be cause the UNKNOWN owner issue? Basically, the owner isn't being set? Still, I can see how this might affect the copies LB makes, but not the originals. I have no clue. 😄

Agreed. I am definitely not sure something else isn't going on. Immich has PUID and PGID settings, but I have doublechecked with the devs and I have them set correctly for unRAID. 99 and 100, respectively. But still, I had other folders unrelated to Immich that were also synced using LuckyBackup that also had all the owners set to UNKNOWN. I've been trying to think of what else might be doing this as it also makes little sense to me that LuckyBackup would alter the owner. There is some database backup software that has access to my database backups, but it doesn't have access to the Immich stuff. So far the only thing I can come up with that has access to all these things is LuckyBackup. I had LB disabled last night and the proper owner was retained. I will watch it over the next few days and see if it changes with LB disabled. Other than screenshots, is there a better way to share my LB settings with you? Thanks!