Why is this still happening to me? (NC needs Focus)

There are other options out there (more angostic not tightly integrated into Nextcloud) like for example Cryptomator.

What restricted filetypes do you mean specifically?

all of them ? :wink: since it is just jebrish to the server should not bring any issues

Could this be an Apache issue rather than a Nextcloud issue? Do you have a FilesMatch directive that matches this file?

no and no
It was an NC bug; I’m guessing most likely coming from the encryption module or could have been a DB corruption too but we will never know; I have since reinstalled everything.

Hidden files aren’t synced by default with the client. Did you enable “Synchronize hidden files” in the ignored files settings?

Yes it has always been selected
Going further, I now deleted restricted files manually as per my other post; now everything is syncing except symbolic links; would love a solution for that
https://help.nextcloud.com/t/how-to-disable-file-restriction-server-side/34512

Since Serverside encryption is bashed here again, I can’t keep silent.

E2EE is great, hope it is ready soon. But there is a reason Nextcloud limited it to folders. Sharing is tricky at best and downloading stuff from anywhere via Website is impossible as the server can not decrypt it for you.

Benefits from Server encryption that I would not like to miss and still hope it is extended instead of being removed in the future:

  • Users that don’t use it anymore/don’t log in anymore can by this virtually instantly delete all files.
  • Users also do not have to worry about backups laying around after deleting an account.
  • If someone attacks the server and manages to get a system dump for offline investigation. He can not decrypt the files, unless he risks to attack the server again and do some sophisticated Nextcloud specific targeted attacks.

BTW. I was running Nextcloud just fine on a Pi2 with multiple users and encryption, a bit slow though, and am now running it perfectly fine on a Pi3 (I use OpenSuse Leap 42 to make full use of it’s 64 bit architecture and allow files > 4Gb as my Family loves to share videos). Last issues of your kind I had on our companys installation back when it was still owncloud. The encrypted flag was sometimes missing the database. But since we switched to Nextcloud these issues are gone :+1:

Can you share your config / optimisation details (especially database, web server and nextcloud’s config.php) anything in particular ?
Any issues with file lock or file not syncing for no reason ? did you change restricted files ?
Are you currently using server encryption ( home folder too ?) ?
Any chance you can develop on the OpenSuse / Debian choice for the “full 64 bit” ?

what does that mean ?

I’ll see if I have time for something detailed. The basics are:
LUKS encrypted disk
OS: openSUSE Leap 42.3
Nextcloud 13 + Encryption module
Database: mysql 10.0.34 (Default package manager)
PHP 7.0.7 (Default package manager)
Apache: 2.4.23-22.1 (Default package manager)
Letsencrypt certificate

Notable Apache config tweaks:
Protocols h2 h2c http/1.1
KeepAlive On
MaxKeepAliveRequests 200
KeepAliveTimeout 300

Nextcloud configs:
‘memcache.local’ => ‘\OC\Memcache\APCu’,
‘filelocking.enabled’ => true,
‘memcache.locking’ => ‘\OC\Memcache\Redis’,
‘enable_previews’ => false,

There is a column in the database saving for each file if it is encrypted or not. And back then it happend from time to time, that the file was encrypted correctly and everything but for some reason the dattabase flag said, it is not. Causing hte sync problems.

I could find such files with this statement:

select * from oc_filecache where (path like 'files/%' and encrypted = 0) and mimetype != 2 ;

Saying: Select all entries in filecache that are files and and are not marked as encrypted

I won’t put the very simple sql fix for this in here, as I don’t want anyone run it, without knowing what he does and causing trouble. Again this was back when it was owncloud, so no Idea if this is still working on nextcloud anyway.

Update: Data is stored on an external Samsung SSD that is connected via USB to the Pi3

That is probably sufficient.

Doesn’t really add a lot and you will have a lot of bugs. Check the bug tracker (https://github.com/nextcloud/server/labels/feature%3A%20encryption%20(server-side)), there are numerous bugs which are not really fixed and it’s unclear when it will be the case. Or get enterprise subscription to be able to have someone to call in case it goes wrong.

No it is not. See the points I made. But a minimum for burgler protection. Also wiping the disk after its end of life is far easier/not neccessary.

For this I have daily backups. But I hope the quality in this officially supported feature will be better soon.

Of course, if there is no master key set up. Otherwise a malicious admin (or somebody who phished/got the password) could decrypt everything. And if an attacker already is in your system running Nextcloud, they can change the login page to dump the passwords of those users. This can only be mitigated by E2EE, not server side encryption.

Aside from that, many apps don’t support server side encryption and as @tflidd said, many bugs are still unsolved. There isn’t even a tool/script to decrypt encrypted files in a disaster recovery scenario where the database or the rest of Nextcloud is gone/not working anymore.

Obviously. One should not need this feature anyway, because anyone sane has backups of his data. What if the host goes away tomorrow for whatever reason. So I stand by my 3 points. They are of real value.

…could phish the gullible user for his/her E2EE password. :wink: I’m far more concerned with the “weak” admin, who in a weak moment decides to poke around his users stuff. It’s a huge gap between doing this and such an highly illegal attack.

Yes so much unused potential. What a pitty, especially as it’s nearly done already. There could easily be a transparent solution for apps to also be able to encrypt the data. Encrypted calendar/contacts would be awesome.

Master keys should definitely not be used as some kind of “backup” system. But still, restoring single files from a system with server side encryption enabled is a nightmare. There is no easy way to decrypt it with the password and the encryption keys anyway. The feature itself might be useful for organizations with regulations they have to adhere to and a huge untrusted 3rd-party storage space.

Yes, users should be trained well and not that gullible. Lets see how the E2EE concept proposed by Nextcloud (there is a full specification on Github after all) will work out in practice. Advanced users already can use cloud agnostic E2EE tools like Cryptomator that upload nothing in plain text and certainly no passwords are sent to the Nextcloud instance because they only enter it on their desktop/mobile systems directly inside the app. With server side encryption there is another angle of attack where the admin or anybody with full control over the system could also just take the data before it is encrypted and placed onto the storage. Impossible if it is already sent fully encrypted there.

Could be as easy as using the “impersonate” app and just use the app for what it is supposed to do.

Would make it far easier for 3rd party apps and tools to interface with server side encryption.

Encrypted contacts/calendars would be 100% incompatible with current Caldav/Carddav standards Nextcloud adheres to and require a completely different and incompatible client for that as well. Adoption for such a solution would be very difficult for sure and it would have to be done by 3rd-party developers anyway.

Interesting conversation. loads of very important details. What I am getting out of it is that server encryption was shipped half baked and there is a chance that E2EE could go the same route (if it even gets “ready” in NC14). I hope not

I am convinced E2EE is the only way to go since IMO on top of being the most secure it also has the potential to solve the problematic file syncing types like .htaccess and others

So at the moment, as far as I am concerned, NC does not have a stable/usable encryption implementation.

Since I disabled encryption a week ago I don’t have any error yet; coincidence ?. Is the German gov using encryption ? Magic ?

Maybe time to refocus dev time ?

Absolutely by no means at the same level, at least for now. Server side encryption was introduced in the old Owncloud days and developed behind closed doors with little input from security experts. It was completely redone two times (!) with to major releases which was really bad for early users.

E2EE on the other hand is implemented in the open and there is an RFC on Github with the specification: https://github.com/nextcloud/end_to_end_encryption_rfc
Basically everybody can follow development and audit their approach (if you know a reputable cryptography expert that can help they surely wouldn’t say no :wink:).

Not integrated seamlessly into Nextcloud, but cloud agnostic tools like Cryptomator do a good job. Anyway, the “its done when its done” approach is far better than having some rushed in non-solution that doesn’t work.

Probably no coincidence. Had systems with really big problems, got rid of server side encryption and everything is just plain awesome. And I don’t think the German government stores its data at for example Amazon :wink:, which would be use the case for server side encryption (non trustworthy external storage), but who knows.

It was always open source and also some additional information but not the same approach like for the E2EE. However, it was hard to follow why and how this module changed…

I heard this a couple of times, however I have no statistics, perhaps there are tons of users who use encryption successfully. I would be interested how often this feature is used by enterprise customers…

Using unencrypted setups is less scary if it is on your own server. I can understand that people on shared hosting appreciate such a feature even though the protection is somehow limited. It just prevent admins or people who gain access to easily read files. However, server-side encryption should run certain commands from the command line where there are normally no timing restrictions, so the process can finish properly. And especially this is very critical on shared hosting because you don’t have terminal access at all or it is often very restricted as well. So in this situation it is even more likely to experience issues.

In these cases, not using encrypted setups has two advantages: you don’t risk to have these issues and you are aware that the admin can read stuff. I think the worst thing to happen is that you trust the crypto even though in this particular situation it can’t be trusted. If you don’t have this encryption, you will more likely put sensitive stuff in additional encrypted containers or don’t share sensitive information at all. Other way would be to use a provider storage for some less important data, but if your contacts or calendar is too sensitive, you still can run it on a setup at home (Raspi etc.).

If you need file syncing only you might want to consider using Seafile. The performance regarding syncing small or big files is still very fast.

Thanks a lot !! That software looks like a dream: open source, written in C, file versioning, client side E2EE and IOS app. Giving it a try very soon :love_you_gesture:

1 Like

They had a few bugs in their encryption (not sure about the status and if there was a serious review), and the open source stuff stinks a bit since many interesting features are only available in the proprietary commercial version. If it is only for the best sync performance possible, I’d rather check syncthing or git-annex (and for more skilled users: rsync). You can still use such a folder as external storage for Nextcloud, if you prefer the webinterface to share files with others.