mjdamato

That was it! I was digging into the repository thinking I needed to use the GUID associated with the version or some such value associated with the release. Thanks again.

Yes, makes sense. Thank you! I had expected that the template for the Unraid Docker from CA would have included the parameter to map /data to the appdata folder. You stated it was working for you, so I wonder if that parameter got dropped along the way in a later update of the template. I certainly don't want to question the dev who created the docker template as I'm not all that familiar with the dockers and am just benefiting from others work. If I can ask one unrelated question. The current version of Homebox has a bug that kills the session when opening a record with a PDF attachment. The only workaround at this time is to downgrade. In my docker configuration I have the value Repository: ghcr.io/sysadminsmedia/homebox:latest. I know I need to replace the :latest tag to the value for a specific prior release. I've tried changing repository to ghcr.io/sysadminsmedia/homebox:v0.23.0 (which is the version prior to the current bug) and clicking apply and applying, but that isn't working (error below). Am I using the wrong format, or is the tag some other value I'm not finding? Thank you again for your help. --restart=unless-stopped 'ghcr.io/sysadminsmedia/homebox:v0.23.0' Unable to find image 'ghcr.io/sysadminsmedia/homebox:v0.23.0' locally docker: Error response from daemon: manifest unknown. See 'docker run --help'. The command failed.

Sorry for the delayed response. Notifications weren't enabled for me on this forum. I guess I don't know that and I'm not really following you. Let me restate what I found to make sure I didn't misstate something: After installing the homebox docker and using the application for a while, the data under appdata\homebox had not been changed since I first set up the docker. There were three files related to the DB but they had never been changed since setting up the docker and there were no files related to the many files I had uploaded. I then found that the same three file names for the DB (with newer date/times) and all the images I had uploaded were instead contained within the docker image. So, when I made changes they were only written to the docker image, they were not getting written to the adddate folder. It was my understanding that the appdata share was for storing the "data" for the dockers and the docker image was to hold all the "logic" needed to run the docker. I'm not terribly versed in how the dockers work but, based on your last comment, are you saying that when a docker is started it should load the data from the appdata location into the docker container? I could see where that would make sense. If that is the case, shouldn't the homebox data get written back to the appdata folder at some point? Mine never was - the data was only ever updated in the docker image. Also, many of my dockers have a configuration for the container to set the appdata location. E.g. My Plex docker has a "AppData Config Path: /mnt/user/appdata/binhex-plex" and my Duplicati docker has "Appdata: /mnt/user/appdata/duplicati". Some don't have a setting and neither does my Homebox docker. But as soon as I added a new parameter for the Homebox docker, as noted in my second edit, to set and set the location to the appdata folder I could see that data was being written to my appdata folder as I made changes. I assumed that this is how it should work. If this is going to cause problems I would appreciate some guidance. I was just trying to prevent my docker image from growing too large because of all the files I am uploading to homebox. EDIT: OK, after some trial and error. I see that when I am making changed within homebox it is now updating the files in both the docker.img (when accessed via the container console) and within the appdata\homebox directory. I am guessing that the results I get from the console looking inside the docker.img are maybe just a pointer back to the appdata/homebox folder. That all makes sense now. But I still don't know where the data was being stored before I added the config path entry to the docker template. The files were absolutely not being stored in the appdata/homebox directory.

Here's the diagnostic file. I've also discovered some more info on the problem. The Unraid server shows up in Windows Explorer as HomeNAS (which is the name of the server and how it has always appeared). When attempting to open that network computer it would have shown me the available shared in the past. When I try now, windows cursor will spin for a good while then report "Windows cannot access \\HOMENAS". . However, If I type in \\192.168.0.10\sharename \OR \\homenas.local\sharename\ into windows explorer I can access the shares. Not sure why the old format is not working. Now that I am able to access the server, I do have a flash backup that is only a week old vs. the one I used which is three weeks old. If this problem is due to some configuration mismatch due to the age of the backup, like the Tailscale issue above, I'm half tempted to reflash with the later backup. TIA diagnostics.zip

My Flash drive was failing and I went through a long ordeal to get a new flash drive working. That involved making BIOS changes, a couple different flash drives and trying to restore multiple different backups. Finally have it up and running from a three week old backup. But . . . I could no longer get to the server WebGUI from other PCs and the shares are not available on the network. I confirmed that the server had internet access and the internal IP address (192.168.0.10) had not changed. I had just recently set up Tailscale on the server before the flash dies and the backup I restored from was from before I installed the Tailscale plugin. So. I went to the Tailscale site and removed the route to the Unraid server. I could then get to the Unraid GUI from another machine - yay! I could see the unraid server on the network, but I cannot access the shares. I went back to the Tailscale site and removed the Unraid server and my other machines from the managed devices. Still no luck. I'm not sure if the issue with the shares is some other config issue due to Tailscale or something else entirely. I'm just really at a loss. Everything had been working for years before I had to replace the flash drive. Any ideas on what I should be looking at?

Where's the data stored? I must be missing something obvious. I installed the docker back in Sept. and had imported my inventory from a prev. system, uploaded all the photos, etc. I noticed that the files in the user\appdata\homebox share showed no updates from my activities and I couldn't find where the data was being stored. But everything was working and I went on to other things. I had accessed it a few times since then without issue. Today I opened the docker and it wouldn't recognize my credentials (stored in PW manager and never changed). I re-registered and all the data was reset to the default for a new install. I imported my initial data again (luckily saved the import file) and will have to do all the other updates I have done. But, even after all the changes I have made today, I see that there are only three files in the user\appdata\homebox share (homebox.db-wal, homebox.db-shm, and homebox.db) and they have a last modified date of 2025-09-19. I checked the docker configuration and don't see any parameters to define where the docker data is stored for homebox. I want to ensure I know where the data is stored so I can back it up to prevent another data loss. EDIT: OK, I've found the problem. The Docker image has the same three data files (homebox.db-wal, homebox.db-shm, and homebox.db) as exist in the user\appdata\homebox share. It is those files that are getting updated. I would think the docker should be storing the data in the appdata share and not the docker image. Not sure if there is a reason the data is stored in the image and if there is a way to change it to store the data in user\appdata\homebox - preferably without losing any data. EDIT #2: So, I dug into the documentation for Homebox and found the following configuration within the default compose.yml file: homebox-data: /data/ I then created a new configuration option in the Homebox Unraid Docker with the following options: Config Type: Path Name: homebox-data Container Path: /data/ Host Path: /mnt/user/appdata/homebox/ Access Mode: Read/Write After restarting the docker, it was again acting as if I had not registered (expected if it was using a different storage location). After registering, I was gain faced with a new system and the default entries. I imported my last export to get back to where I last was (without images). I could then see that the files in the appdata share (user\appdata\homebox) were now being updated as I made changes in Homebox. I believe this is how it should be configured. Please advise if this is problematic. I will continue to verify that everything continues to function as expected.

You can but, in my case at least, that created issues with Gmail having already marked the messages as read because I was sending them to myself and they did not show up in my inbox. I had to use the + hack to modify the alias ([email protected]) and them create a rule to ensure they did not bypass the inbox or arrive as already read. Although they still showed as From: me in the display. It was just easier to create a second gmail account with a name that was easily identified as being a notification from my unraid server.