Optionally disable "--chown www-data:root" when upgrading

[e-minguez]

Using nextcloud in containers with NFS as backend storage for /var/www/html (with proper anonuid=82 and anongid=0 to match www-data:root ownership), the rsync process complains:

rsync: chown "/var/www/html/whatever" failed: Operation not permitted (1)

Using the NFS flags already mentioned ensures the ownership so there is no need to change it (and if you want to do it, it fails).

I guess having an environment variable that is used by the entrypoint.sh script can be good enough (?)

[skillpoint-dev]

Having the exact same issue. Setting up nextcloud with the official helm chart and using PV NFS. Why isn't this marked as bug but in the sub-issues marked as "enhancement" @e-minguez?

[e-minguez]

Having the exact same issue. Setting up nextcloud with the official helm chart and using PV NFS. Why isn't this marked as bug but in the sub-issues marked as "enhancement" @e-minguez?

Well... I'm not sure if being able to use NFS as backend storage is a feature, so not sure if this can be considered a bug :) I'll let the nextcloud folks to decide :) Meanwhile, I'm using https://github.com/e-minguez/nextcloud-container-nfs-fix as a workaround just in case you want to take a look

[ervinpm]

I was able to resolve this by adding a no_root_squash in the /etc/exports file of the NFS server.

[e-minguez]

I was able to resolve this by adding a no_root_squash in the /etc/exports file of the NFS server.

My main concern with this approach is it can be considered a security issue. For example https://book.hacktricks.xyz/linux-unix/privilege-escalation/nfs-no_root_squash-misconfiguration-pe

[martadinata666]

well with NFS, either build custom image ourself to match our deployment, i use all_squash,anonuid=1000,anongid=1000 , or no_root_squash.

[fletchowns]

I was able to work around this chown issue when using NFS mount for /var/www/html by leveraging #1812 and specifying user: '33:33' in my docker-compose.yml (uid & gid for www-data). Running as a non-root user causes the problematic rsync options to be avoided in this conditional.

[vjku]

Got NAS storage (external windows share on same LAN) with rsync working on a Proxmox Host with the latest CentOS 7 x64 Minimal ISO by running this mount command with uid,gid args before docker compose up -d is executed.

mount -t cifs -o username=win_user,password=win_user_pass,iocharset=utf8,uid=33,gid=root,file_mode=0640,dir_mode=0750 //IPv4.Of.Win.Server/path/to/nas/share/1 /root/nextcloud/nas/nas1;

Test the mount on VM before deploying docker containers. Add to either /etc/fstab or setup a reboot cron to execute above so the NAS remains mounted even after VM reboots.

Here is the Docker Compose file

version: '3.8'

services:
  db:
    image: mariadb
    command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW
    restart: always
    volumes:
      - ./nextcloud/mysql:/var/lib/mysql
    environment:
      - MYSQL_ROOT_PASSWORD=keep_this_secret
      - MYSQL_PASSWORD=do_not_tell_the_world
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
    networks:
      - nextcloud

  redis:
    image: redis:alpine
    restart: always
    networks:
      - nextcloud

  app:
    image: nextcloud
    volumes:
      - ./nextcloud/app:/var/www/html
      - ./nextcloud/usr:/var/www/data
      - ./nextcloud/nas:/var/www/nas
    depends_on:
      - db
      - redis
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Asia/Kolkata
      - NEXTCLOUD_ADMIN_USER=admin
      - NEXTCLOUD_ADMIN_PASSWORD=admin
      - NEXTCLOUD_TRUSTED_DOMAINS=IPv4.Of.Docker.VM
      - NEXTCLOUD_DATA_DIR=/var/www/data
      - MYSQL_HOST=db
      - MYSQL_USER=nextcloud
      - MYSQL_PASSWORD=do_not_tell_the_world
      - MYSQL_DATABASE=nextcloud
      - REDIS_HOST=redis
    restart: always
    ports:
      - 80:80
    networks:
      - nextcloud

  cron:
    image: nextcloud
    restart: always
    volumes:
      - ./nextcloud/app:/var/www/html
      - ./nextcloud/usr:/var/www/data
      - ./nextcloud/nas:/var/www/nas
    entrypoint: /cron.sh
    networks:
      - nextcloud
    depends_on:
      - db
      - redis

networks:
  nextcloud:

Now rsync works from another Linux machine. Web GUI file can be edited and the same can also be modified from Windows NAS server.

echo "test_file_rsync_from_another_host" > ./test_file_rsync_from_another_host.txt;
rsync ./test_file_rsync_from_another_host.txt root@IPv4.Of.Docker.VM:/root/nextcloud/nas/nas1/

Hope this helps someone :)

[ghost]

This is also affecting us. Our deployment infrastructure is a kubernetes with PodSecurityPolicies (similar to the strict OpenShift defaults). We are not using NFS as a backend but PVCs

Our helm values.yaml

persistence:
  enabled: true
  storageClass: 'ceph-filesystem'
  size: 8Gi
  nextcloudData:
    enabled: false

[flypenguin]

this is also a blocker for deploying with AWS EFS it seems ...