primeval_god

Has anything changed on your system recently? Any changes with your stacks? Anything in your system log?

When creating a stack there is an advanced option (in a dropdown at the bottom) for specifying the project location. If you need to add extra files to the compose project (such as a build directory) you should select a project location on a pool or array.

It definitely will. No one has ever suggested that it wouldnt, as it continues to be the defining feature of unRAID. I believe they are working toward that, but i dont like to speculate on when Soon™ will be.

unRAID requires a 64bit processor. https://docs.unraid.net/unraid-os/getting-started/

Pools can be single drive XFS, BTRFS raid, or ZFS raid. The "Array" is the only one that can be Limetech's proprietary unRAID storage (mix and match file systems and disk sizes with up to 2 parity drives with max 30 total drives). The terms pool vs array and the fact that there must be an "Array" on an unRAID NAS are products of unRAID's slow evolution. From what I understand in a future version the term Array will go away and the unRAID storage type will become a type of pool and the requirement of always having an unRAID type array will be removed. As to whether or not multiple unRAID type pools will be supported that is likely even further in the future. Also currently pools can be used to "cache" new incoming files that are then moved to the array (pools are an evolution of the older cache drive concept). In a future version the mover will support moving files between pools rather than only to and from the array.

The above is the key thing to understand. An "empty" drive with a file system is not empty. But even if it a drive were truly empty it would not matter. Parity happens at the lowest layer. If a disk is part of the array (and the array is up) then when ever you write data to (or erase) a block on that disk an update is made to parity. You can write zeros to every block of a disk while the array is running, effectively erasing everything including the file system, and parity remains valid. It is only if changes are made to a disk outside of a running array that parity is invalidated.

The parity calculation is done at the block level, for every data block on a disk. It does not care what is stored in that block, the block can even be all zeros in the case of a zeroed/unformatted disk, its all just bytes to the parity calc. Not necessarily, after the last drive is converted you could move the data back to that drive and convert your largest drive back to parity. Not sure what you are getting at here. Once you have emptied a drive you can reformat it while the array is running and parity will be maintained.

There is no ETA for updates but likely not until after the holidays. The code is on github but this thread is all there is so far as support and info.

That is totally understandable which is why I originally proposed something like 2 threads for each new release. One would be in the Announcement subforum and be locked and the other, for people to discuss and provide feedback in, would be posted in another sub and linked from the announcement post. The goal would not be to dampen discussion just to make a clearer distinction (from a notification perspective) between real Limetech announcements and responses to those announcements.

It was an update to docker compose. They changed something about how they reference networks, which interacts badly with how unRAIDs webui detects network names.

No, the Dockerman system has its own method of storing the current and latest available version of docker images. Compose.Manager does not integrate with Dockerman in this respect (in fact it does no update tracking of its own it just provides a button with runs a stack update command). No, at the moment there is no good way to remove the "Update Available" link. The pings are from the Fix Common Problems plugin correct? Best to just disable the update check in FCP.

The place to report / discuss this in the unRAID forums is here, at least i am pretty sure that is the same issue. As for reporting the issue upstream i havent a clue where to go.

No i wouldnt, but what i consider an acceptably complex password for a device on a home network is likely well below that of someone who thinks 2fa is worthwhile. If unRAID were a multi user system, or enabled SMB users to change their own passwords, I could see having a policy setting, but for a single administrator system I dont see a point. Do they have a password strength graphic for the initial setup (its been so long since i did initial setup i dont remember)?

If you open a shell in the container can you view the contents of the mounted folder at /disks/veraaa/veraaa ? There might be something wrong with using /mnt/disks on the unRAID side, i think other plugins may use that folder, not entirely sure. It looks like it should be mounted at /mnt/disks/veraaa, can you see that from the unRAID shell?

There are several , though i wouldnt agree that we all think it should happen. Absolutely not, If i want to set my password to 'password' on my own system that is my prerogative.

Well that is the big one. The root user (which is the only real user) is meant for management and should be used sparingly. And your asking whether other uses accounts can have access to the unRAID os which is not how its meant to be used. But more generally docker is the preferred way of extending functionality on unRAID. Anything that can be done with docker, should be done with docker. It helps to isolate user customization from the unRAID os. In this case it would allow you to easily ensure your file transfer client only has access to the specific folders that it needs access to.

You should not connect directly to unRAID via ssh or sftp to transfer files. A better option would be to setup a docker container (or LXC container if thats more your style) to host an ssh or sftp server for file transfer. You could configure whatever usernames and permissions you need in the container.

Also no icon is specified but i like this one http://www.top-windows-tutorials.com/images/2013/04/veracrypt-logo.png

For the webui field you always specify the container port not the host port. The rest is pretty self explanatory, except for the disks bind mount '-v /mnt/disks' which needs this option.

No idea Swapfile support is available thorough a plugin.

Off hand i think deleting the override files wont cause a problem. I am pretty sure they will get recreated any time the compose stack is edited in the GUI.

I havent, I will have to look into it. But I am not sure that it addresses the root of my wish to differentiate between an actual new announcement made by limetech, and other people discussing or responding to that announcement.

No not at this time.

Seeing these comments, I was reminded to bump this old request.

Note that the version of CA that you are currently using will likely to function for a while, at least until incompatible changes are made to the appfeed. I am also still on unRAID v6.11.x and I am not feeling compelled to update as of yet.