Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Invalid handling of mounted volumes in Kubernetes #24971

Closed
Expro opened this issue Jan 5, 2021 · 1 comment
Closed

Invalid handling of mounted volumes in Kubernetes #24971

Expro opened this issue Jan 5, 2021 · 1 comment
Labels
0. Needs triage Pending check for reproducibility or if it fits our roadmap bug

Comments

@Expro
Copy link

Expro commented Jan 5, 2021

How to use GitHub

  • Please use the 👍 reaction to show that you are affected by the same issue.
  • Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
  • Subscribe to receive notifications on status change and new comments.

Description:
Mounted volumes in Kubernetes are always mounted with root:root (0:0) permissions. Nextcloud looks at those permissions and declares /data directory non-writeable, event if it is actually capable of writing inside this directory. Nextcloud needs to be a bit smarted and actually probe writeability OR recognize it is being ran inside container and suspend this check OR allow itself to be informed via environment variable that this check should be ignored.

Logging into container and doing "chown 33:0 data" (without -R) makes this error go away, but that's not sustainable. There is workaround with initContainers (https://stackoverflow.com/questions/43544370/kubernetes-how-to-set-volumemount-user-group-and-file-permissions), but it would be nice if Nextcloud would require no workarounds.

Steps to reproduce

  1. Prepare Kubernetes environment.
  2. Create Deployment or StatefulSet with Nextcloud image and /var/www/html/data directory mounted as volume, with correct file permissions.
  3. Go to IP / FQDN for newly created Nextcloud instance.

Expected behaviour

No "data is writeable" error, everything works correctly.

Internally: Nextcloud probes permissions and ability to write inside /data and recognizes that all is right.

Actual behaviour

Receive "data is not writeable" error.

Internally: Nextcloud just looks at user and group owning /data and declares failure.

Server configuration

Nextcloud version: (see Nextcloud admin page)
20.0.4

Updated from an older Nextcloud/ownCloud or fresh install:
Updated.

Where did you install Nextcloud from:
hub.docker.com

Are you using external storage, if yes which one: local/smb/sftp/...
Issue with all types of mounted volumes (tested with NFS and GlusterFS).

Are you using encryption: no

@Expro Expro added 0. Needs triage Pending check for reproducibility or if it fits our roadmap bug labels Jan 5, 2021
@szaimen
Copy link
Contributor

szaimen commented Jun 22, 2021

As this sounds like a nice feature, the requests for this are quite low. Currently there are no plans to implement such a feature. Thus I will close this ticket for now. This does not mean we don't want this feature, but it is simply not on our roadmap for the near future. If somebody wants to implement this feature nevertheless we are happy to assist and help out.If you wish to have this feature implemented by the Nextcloud GmbH there is the option for consulting work on top of your Nextcloud Enterprise subscription to get your features implemented.

@szaimen szaimen closed this as completed Jun 22, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
0. Needs triage Pending check for reproducibility or if it fits our roadmap bug
Projects
None yet
Development

No branches or pull requests

2 participants