primeval_god

The webui button "Update Stack" is what you are looking for.

@benfishbus A new version of the plugin is available which I believe will solve your issue.

No need for that.

@benfishbus Do you happen to have the unassigned devices plugin installed?

Maybe its something that changed in the latest release. All 4 themes seem to render properly on 6.9.3. I will have to look at what has changed in other plugins. It may look strange but thats what its meant to look like. Thats not it at all. I have 0 web design experience, the interface you see here is cobbled together from bits of other plugins.

I am unable to reproduce this issue locally. It is true that the popups are not themed, but they look fine to me when running the black theme. What version of unRAID are you using?

Try using an online xml validator on your plugin source. I had a similar issue with a plugin I maintain. I dont know anything for sure but it seems like they may have tightened up the XML validation for the .plg. For me I needed to use a XML escape character in place of a character in one of my inline bash scripts.

This is not a safe or recommended environment for unRAID.

Use docker compose ls to list all running stacks. The NAME column has the "project" name that was used to create the stack.

No problem, one last thing to be aware of is that the docker hub page has some bolded text regarding what to expect in terms of security. Make of that what you will.

I think veracrypt has a umask (or some similar name) option in its mount prompt. Try 000 for that. Also make sure the host path is under a properly shared user share.

If you look at the usage section on the docker hub page you will see a bind mount that looks like this -v </path/to/mount/images>:"/mnt/disks":shared \ The shared flag is very important its what allows the mount points to propagate to the host. In this case /mnt/disks is in the container and path/to/mount/images is on the host. When you mount your images in the docker container you must mount them to a mount point (subfolder) inside /mnt/disks. The mounted directory will be under path/to/mount/images on the host.

It would likely depend on exactly what shell commands you are exposing via that app, and what you are doing with them. But this sounds like a bit more complex set of automations than most.

An alternative is to just run the veracrypt gui in a docker container. https://hub.docker.com/r/dcflachs/veracrypt-gui

Dont. Unless it is explicitly required as the dependency of something else i would recommend not installing python on unRAID. Instead you should run your python scripts inside of a docker image. Once you understand the basics of Docker its much easier than it seems at first. It adds a bit of overhead but makes it much easier to manager python environments. See my comment in the linked thread for specifics.

Well thats just great... here i am thinking i am making a fix and really i am going backwards.

https://superuser.com/questions/12972/how-can-you-see-the-actual-hard-link-by-ls You can look at the output of ls and for each file determine if there are multiple hardlinks (including the one you are looking at) to the data.

It would also be nice to have be able to specify the shell to use when clicking "Console" via a label. To that end i have made a pull request https://github.com/limetech/webgui/pull/1152 to add usage of net.unraid.docker.shell. (In additional to my request to fix icon caching https://github.com/limetech/webgui/pull/1146) @bonienl

If you have automatic protection on then I think you should just be able to touch the file and then the plugin will detect the change and rehash.

As far as I am aware there are no Major bugs with this plugin. It seems like most people, myself included, have been running it without issue for several years. If you look back through this thread for posts from Bonienl you will see discussion of some of the limitations of this plugin that can occasionally produce false positives for hash mismatch. Things like too many files changing at once or certain programs changing files in a way that doesnt trigger a rehash. There are also issues I think with running to many disk verifications at once causing hashing tasks to be aborted and return as errors. There are also certain file types that dont really work with this plugin, like large vm disk images which take a long time to hash and can have many small random changes. In my experience though playing in the bounds of what this plugin can handle things work just fine.

Which one fixed it? Or did you try both?

With the stack down try renaming the project directory. You could also try removing docker-compose.override.yml, just be sure that you save your labels so you can add them back later through the GUI.

What do the content of the project directory look like? As for your original error about the invalid compose file, that would be due to a service within the compose file that was missing an image name. Could be a mistake in the compose file or a problem with the override file the plugin generates to add unRAID compatibility labels. Just before you got that error had you edited any compose file outside of the GUI? Or had you renamed any service within a compose file?

Yeah i dont think this is exactly true. From what i can tell it looks like Docker Engine 20.10.13 began providing Docker Compose V2 as an optional package along with their releases. I dont think that translates into it being automatically being available on unRAID.