Yesterday my cache freaked out and started generating IO errors. I received help here to at least identify that my cache config was not going to be directly re-usable. I suspect that at least one of the drives I was using went kaput, so I re-configured to a pair of 1TB drives. (Previously had one big cache pool of 4 misc SSDs. Figure I'll be more organized and use one 1TB drive as cache for appdata and the other as cache for normal cache operations + my docker image.)

 

During my debug and screwing around, trying to figure out what had happened when that drive failed, I started the array with Docker and VM services still enabled. At that time, since the cache was down and I had my array set to be the backup location, it generated my Docker image on a disk in my array. It also made a few appdata files in various places as Docker launched with some containers that didn't need to access appdata started.

 

I've recovered my original Docker image file and original appdata folder contents from the failed array drives and am repopulating those to my new cache. However, if I go through file explorer on Windows and directly try to delete the version of the Docker image that got created when it re-generated it on an array disk (have the setting turned on to show individual drives over SMB), I get an error that says "You require permission from CASTLE/nobody to make changes to this file". 

 

Any advice on how to proceed? I'm sure what I'm doing is bad and sketchy in some way. Diag, for if that's useful here.castle-diagnostics-20250205-0156.zip

You cannot delete those files over SMB, do it locally.

Ahhhh very good. I'm dumb. I was assuming it was some kind of explicit permissions issue or something.

 

Am I correct to assume that deleting files this way doesn't somehow invalidate parity?

10 minutes ago, KingArthur said:

Am I correct to assume that deleting files this way doesn't somehow invalidate parity?

Any write operation (write, copy, move, delete, format) to the array updates parity at the same time.

 

5 hours ago, KingArthur said:

(have the setting turned on to show individual drives over SMB)

I usually recommend against this. If you insist on doing it, make very sure that you don't mix user shares and disks when copying or moving data. That could result in data loss. Might be a good idea to SMB export disks as hidden so nobody accidentally stumbles upon them.

 

Here is an old and long thread (TL;DR) that discusses this:

https://forums.unraid.net/bug-reports/prereleases/60-beta6-user-share-copy-bug-r3007/

 

Here is a short post I made some time ago about this which explains what happens.

https://forums.unraid.net/topic/61985-file-browser-in-webui/page/2/#findComment-723474

That thread ultimately led to Dynamix File Manager plugin

 

You should install Dynamix File Manager plugin. It will let you work with folders and files directly on the server from the webUI, and also won't let you make the mistake of mixing disks and user shares.

 

 

9 hours ago, trurl said:

I usually recommend against this. If you insist on doing it, make very sure that you don't mix user shares and disks when copying or moving data. That could result in data loss. Might be a good idea to SMB export disks as hidden so nobody accidentally stumbles upon them.

Totally understood. I think that when I was looking up how to even turn this setting on I found an old forum response from you where you were cautioning somebody else of the dangers of accidentally doing a disk <-> share copy operation that just deletes the content. Definitely wasn't planning on leaving that enabled.

 

9 hours ago, trurl said:

You should install Dynamix File Manager plugin. It will let you work with folders and files directly on the server from the webUI, and also won't let you make the mistake of mixing disks and user shares.

Very much appreciate the recommendation! I'll add that right now.

 

Dare I say, I think I kind of got away with this one. I had a small handful of files that refused to copy over, but that was just a single video file and then some Plex generated thumbnails from my Plex media folder. Currently though, every Docker container is operating as-expected. Time will tell if anything is unstable, and I'm definitely going to implement better management practices going forward (backing up my appdata and docker image, for example, duh). I obviously did not understand the structure of Docker and appdata stuff and could have really gotten bitten in the ass by this.

1 hour ago, KingArthur said:

(backing up my appdata and docker image, for example, duh

appdata backup is important obviously. That is how each app is able to have its data persist.

 

docker.img backup is not needed. It is easily recreated by reinstalling your containers from Previous Apps. We often have people delete and recreate it when there are problems with it.

https://docs.unraid.net/unraid-os/manual/docker-management/#re-create-the-docker-image-file

https://docs.unraid.net/unraid-os/manual/docker-management/#re-installing-docker-applications

https://docs.unraid.net/unraid-os/manual/docker-management/#docker-custom-networks

 

It is also extremely important to have a current backup of flash. All of your configuration (all settings made in the webUI) are in the config folder on flash. One of the things in there are the docker templates that were created when you installed your containers. That is how Previous Apps knows how to reinstall your containers exactly as they were. Without those, you can't really work with your containers.

 

12 minutes ago, trurl said:

appdata backup is important obviously. That is how each app is able to have its data persist.

Yeah I felt extremely stupid that I hadn't set that up. When I set up this server a few years ago, I don't believe that the Backup/Restore Appdata plugin yet existed (though perhaps one of its predecessors did). I obviously consciously knew appdata was important to maintain because I have some dockers with .yaml files I manually edit that live in appdata, but I was dumb.

 

14 minutes ago, trurl said:

docker.img backup is not needed. It is easily recreated by reinstalling your containers from Previous Apps. We often have people delete and recreate it when there are problems with it.

https://docs.unraid.net/unraid-os/manual/docker-management/#re-create-the-docker-image-file

https://docs.unraid.net/unraid-os/manual/docker-management/#re-installing-docker-applications

https://docs.unraid.net/unraid-os/manual/docker-management/#docker-custom-networks

 

This also makes sense. I think I am just reflexively thinking I should preserve everything. But it's all config from the templates and then just working in appdata and whatever external locations.

 

14 minutes ago, trurl said:

It is also extremely important to have a current backup of flash. All of your configuration (all settings made in the webUI) are in the config folder on flash. One of the things in there are the docker templates that were created when you installed your containers. That is how Previous Apps knows how to reinstall your containers exactly as they were. Without those, you can't really work with your containers.

Thankfully I do backup the flash pretty frequently whenever I make docker changes! And now I have turned that setting on in the Backup/Restore Appdata so I no longer have to manually think about it.

 

Do you have any advice on backing up VMs? Perhaps a recommended plugin? The only VM I run is a Home Assistant OS install, so it's relatively small. Is UrBackup a reasonable option as far as you know? (Sorry for the tangential question.)

2 minutes ago, KingArthur said:

backup the flash pretty frequently whenever I make docker changes! And now I have turned that setting on in the Backup/Restore Appdata

More than one person has needed to access their flash backup but it was stored on their server where they couldn't access it because flash had failed. Be sure you have that backup somewhere you can easily get to it so you can get your server going again.

 

Unraid Connect plugin will keep a backup of your flash on Unraid Cloud.