NextCloud with Wasabi S3 (Part2)

This post is the second part of the previous, the most read one on our blog. After the technical introduction on how to deploy NextCloud using the containerization approach made in Part1, we explained basic functionalities of Wasabi S3, to show in this post, how to glue it all together to get functional and reliable cloud private file-sharing services.

For those who just look for an easy way of using NextCloud services, I would recommend buying ready-to-use offers from many more or less reliable providers giving more or less (usually very little to be honest) customizable functionalities. So if you want to take a shortcut then look here. Also, if you just want to install NextCloud on your VPS in the easiest way possible just to try it out – this post is also not for you, but you will certainly find many others. This post, however, is for those who want to use NextCloud as their basic file sharing system for the needs of commercial activity, which depends on the availability of company data, the possibility of easy professional cooperation, and so everything that increases efficiency affecting the satisfaction of the final customer 😉 Even now, when I’m writing this post, I use a disk connected to NextCloud, which replicates the file with this post to the Wasabi S3.

When we started the NextCloud implementation at NubiSoft we approached it without much thought and we naturally created accounts in NextCloud for each team member and additionally one bucket in Wasabi storage for each of them. In this way, everyone had their NextCloud directory on the local computer (or several of their computers) in which one of the sub-directories was mapped onto a bucket in Wasabi. Every team member had configured it by itself using its own Wasabi API key. And it started a real Armageddon! – Everyone in the company responsible for some area shared on their own some files, in their opinion worth sharing, with others. This led to a lack of control over the structure of the company’s resources, their location, and the management of their availability. After a month, terrified by the growing mess, we backed up all important resources in one place and turned off our NextCloud server to calmly think about what mistakes we made and how to avoid them on the next attempt.

This time, we assumed that the most important thing is security and order in the structure of our electronic company resources, and since they are deposited in Wasabi at the end, the primary goal is to maintain order there. NextCloud (or it could be OwnCloud or something else) is just a platform that provides an interface to our PCs. Our thoughts are illustrated in the implementation diagram below.

We will now show you how to configure the entire system for sharing resources within one group of common interests (on the basis of this, of course, you can create many different groups – e.g. separate for production dept, sales dept, etc.). First, you need to create a secondary account in Wasabi that will not be a root account – this is dictated by security reasons. Then create a bucket or even two as in our case – one will be for everyday files, which are often subject to editing or deleting, and the other for important resources, whose changes will be stored with accuracy to each version and even in the case of logical deletion, it will still be possible access to them. Importantly, for security reasons, the previously created user will be restricted to only the two previously mentioned buckets and the policy mechanism is used for this purpose.

{
  "Version": "2019-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListAllMyBuckets",
      "Resource": "arn:aws:s3:::*"
    },
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::next.corpo",
        "arn:aws:s3:::next.corpo/*",
        "arn:aws:s3:::next.dev",
        "arn:aws:s3:::next.dev/*"
      ]
    }
  ]
}

All that’s left is to set up retention policies in line with our requirements. In our case, we left default values for the dev bucket and event versioning and logging enabled for the corpo bucket. After that, we only generate the API key and we have finished playing at Wasabi.

In NextCloud, for one user who is the head of a given interest group, we configure two external storages.

.. and in the folder view, we have to share these two external storages with a group of interest (defined as a group in NextCloud).

From now on, each member of the group sees (on their PC) two shared folders that are replicated between their computers and additionally stored in a cheap, reliable and secure place at Wasabi Systems.

That is all. And you? What techniques do you use to share and secure your company resources with the team?

Another view angles

  1. You may ask why we use Wasabi versioning for the corpo bucket since NextCloud also implements versioning? Well, versioning in NextCloud, because it is implemented on local resources (i.e. in our case VPS) is volatile and therefore we do not trust him too much. VPS itself has an availability of 99.95% which is a much smaller indicator than Wasabi Cloud.
  2. Does the above mean that NextCloud versioning is not useful for us? Nor! Once a perplexed teammate asked me if I would be able to recover a file that he accidentally overwrote, and it wasn’t a file from the versioned corpo directory, but from the ‘plain’ dev directory. I told him to recover the file using the NextCloud web client – the NextCloud platform is great in this respect – it manages the number of stored versions itself depending on the free disk space. Although our VPS is not very big, thanks to NextCloud we can recover versions of all files even a dozen or so days ago.
  3. You could ask how stable our NextCloud implementation is and do we have any problems with it? Absolutely none! Look at the picture below!

6 replies on “NextCloud with Wasabi S3 (Part2)”

I do not know if it’s just me or if perhaps everyoone else experiencing issues with your website.
It appears as if solme of the ttext in your content are running off the screen. Cann somebody else please provide feedback and let me
know if this is happening to them too? This may be a problem
with my browser because I’ve had thiss happen before. Many thanks

Thank you very much for paying attention! What do you mean by “your site” – blog or home page? Please tell me what operating system and version and your web browser and version you are using. We will then check whether we can confirm and fix this drawback or whether it is specific to your configuration.

A year later – curious if this is still working for you? I have been playing with it – but it appears nextcloud native encryption is broken when using S3 as primary or external storage. Are you comfortable with Wassabi encryption/security?

Trying to consider all options before deploying!

I’m not exactly sure what you call native encryption. NextCloud uses industry-standard SSL / TSL encryption when communicating with S3. And we had no problems with that. With many S3 service providers, you can additionally enable data encryption on their storage devices – so that they themselves cannot see the data that you own.

Leave a Reply

Your email address will not be published. Required fields are marked *