Jump to content

primeval_god

Community Developer
  • Posts

    871
  • Joined

  • Last visited

  • Days Won

    2

primeval_god last won the day on June 4 2023

primeval_god had the most liked content!

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

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

primeval_god's Achievements

Collaborator

Collaborator (7/14)

249

Reputation

10

Community Answers

  1. The only correct way of using this plugin is to create a stack through the ui.
  2. If you created the stack using the UI then you will still need to pull the git repo to get the dockerfile in order to build the project. As mentioned this is venturing beyond the supported functionality of this plugin. That said if you cloned the repo into another folder say `/user/mnt/appdata/path_a/build` and then change the line `build: .` to `build: user/mnt/appdata/path_a/build` that might solve your issue.
  3. Just ignore the "update ready" text for containers created via compose, they are not correct. The update tracking feature of the webui does not apply to containers not created via the webui. If you believe there is an update available for a container created with the compose plugin, there is an update stack button on the compose page you can click.
  4. Its a cool idea, but unlikely to be helpful except for the rare case of actual bitrot. For things like overwrite, accidental deletion, corruption due to software error, etc. the parity drive will be of little to no help because unRAID maintains real-time parity. Any changes made to the file under normal operation are immediately reflected in parity.
  5. There are no plans to support compose stacks other than those created through the webui. The default location for stacks created via this plugin is on the flash drive. That default can be changed via the settings screen, or when creating a new stack there is an option to specify where it should be created. This plugin provides a webui for people to create and manage simple compose stacks on unRAID. It exists primarily because unRAID's Dockerman lacks easy support for multi-container applications. It is not meant to be a full fledged, all features included compose interface. As such its not really geared for large, complex off the shelf compose projects you might want to pull down for github, but rather simple single compose file projects. For a full fledged compose experience i would recommend something like Portainer.
  6. There is nothing inherently wrong with USB3 flash drives that make them incompatible with unRAID. At one time (possibly still today) some motherboards had issues booting from USB3 drives but not from USB2 drives. I think those issues may have also included a tendency for the USB3 drive to drop offline periodically but dont quote me on that part. Additionally USB3 drives, particularly smaller form factor ones, tend to run much hotter than their USB2 counterparts, overtime that is probably not good for the flash memory. If those problems dont apply to your flash drive/mobo then a USB3 drive will likely work just fine.
  7. That shouldnt be a problem. Perhaps its a permissions issue? Do the permissions on the apps_groups.conf file match those of the other files in /etc/netdata? I assume you restarted the container after adding the config file, but if not that should be done as well.
  8. If you select the "file descriptor limit" graph labeled fds in the side bar, then one of the dimensions on the graph should be shfs. I use an older version of the ui so i just annotated your screen shot with where to look.
  9. Under the Applications section, the graphs should now have a shfs line. For this specific issue the subsection apps.files will give you the number of open files for the shfs process.
  10. The app store is not a built in component, it is community run and none of the apps are officially endorsed by unRAID. That said the important thing is that the unRAID host os not be exposed directly to the internet. Containerized apps are safer to expose (behind proper authentication) as they run isolated from the host os. The recommendation though has always been to use a VPN to access your home network and access all your services.
  11. You will need to obtain a copy of the apps_groups.conf file from the netdata container. You can use the docker cp command for this. From the command line, in the appdata folder where you store your netdata configuration, run docker cp netdata:/etc/netdata/orig/apps_groups.conf apps_groups.conf assuming your container is named netdata. Add the line shfs: shfs to the end of the apps_groups.conf file. Then all you need to do is bind mount the file back into the container at the path /etc/netdata/apps_groups.conf (add the entry to the docker template, make sure both the host and container paths are to the file itself).
  12. Can you see the files from the command line? If so the issue may be with permissions of the share and or the underlying data. If the issue is permissions unRAID has a tool for correcting the permissions of your data. If you already have Docker apps setup the new permissions tool can cause issues, but there is a plugin (Fix Common Problems I think) that has a docker safe new permissions tool.
  13. Not that i am aware of. The icon, webui and shell are the only ones that I know of.
  14. If you happen to use Netdata for system monitoring you may be able to spot the circumstances leading up to the crash if the open file limit is the issue. Netdata has a section under Applications (apps.files) that shows the open files for different process groups. By default SHFS is not listed, but its open files are likely group under system or other. With a little customization of the netdata config you can make shfs show up as a separate entity. (Creating a custom apps_groups.conf file in the container and adding line like "shfs: shfs")
  15. I preferred the orange text in the old dark mode. The text in the new dark mode feels to bright. The rest of the styling looks great though.
×
×
  • Create New...