eek

Kaldek is correct that the real attack vector isn't going to be attacks from the internet but rather attacks from malicious code hidden within existing plugins. Now thankfully most of these plugins are small python that can be easily checked but some checks are going to be needed somewhere to stop malicious changes being made. And probably an education effort (even if it's just a warning banner) saying Dockers and VMs should 1) only come from trusted sources 2) only grant access to the folders they need access to and absolutely NOTHING else.

Yes - my mistake as I'm not at home to look at the portal. Without ZFS and as btrfs is really not ready for Array use it's not really a goer...

https://github.com/zfsonlinux/zfs-auto-snapshot/wiki/Samba has a nice outline for what is required to do this with instructions for Debian. It doesn't look that difficult if the drives are configured for ZFS (as I suspect is most people's arrays will be nowadays) and the files are written directly to the array - cache drives would add a lot of additional complexity...

For those who won't have seen it now the new look and feel as part of 6.7 is a great improvement. One (very minor) suggestion would be to start paging at 24 apps rather than 25 as you currently end up with a lone app at the bottom of the screen.

Thanks, that fixed it.

It seems that a recent change to Mylar has broken a lot of container based installations including my instance https://github.com/evilhero/mylar/issues/1929 has the bug report and a suggested fix

32gb having bought an additional 16gb last week. That's for a couple of VMs I'm planning to add as soon as I get a chance... Until now the 16gb available was enough for the Dockers I'm using...

eek, like you, i have installed joch's s3backup docker. i also have a "+" in my AWS secret code field. i dont see any indication that the docker has ever run and the docker log file is nearly empty (it has no err msgs). what specifically did you change to finally get this docker running? thanks, Kevin Sorry never noticed the question until now. I just regenerated my secret code until I got one without a + in it....

Possibly but that's not the point especially when no encoding should be involved between a webform post request building up and executing a command line instruction. The container's portal page give you a textbox in which you enter your access key and another one in which you enter your secret key. Everything I enter there should be transposed (without change) to the command line that launches the container. That wasn't the case resulting in the docker failing to run. Can you tell me where the appropriate place to raise a bug for the following:- Containers may inadvertently not run due to an inappropriate urldecode call transposing values entered in a container's config webform before the command line instruction is executed resulting in the container being passed incorrect values (that differ from those entered by the user on the container's config webform). As an example AWS randomly generates access and secret keys that may or may not contain + symbols. Where the key containers that + symbol joch's s3backup's container will fail to run due to the + symbol being replaced by spaces in the command line instruction generated by the config page that is used to start the container.

Just to say that this works brilliantly provided your account's access key / secret key does not contain the + symbol. It took me ages to work out why it wasn't working but I eventually saw that the + symbol had been transposed somewhere along the line into a space character resulting in an invalid command being sent to aws. I'm now happily transferring 20gb of photos to AWS...