Opensuse vs Nextcloud-AIO Docker user wwwrun vs www-data

ℹ️ Support
, , , , ,
1

The Basics

  • Nextcloud Server version: 33.0.5
  • Operating system and version: openSUSE Leap 16.0 (6.12.0-160000.33-default)
  • Web server and version: Apache/2.4.66 (Linux/SUSE)
  • Reverse proxy and version: Apache/2.4.66 (Linux/SUSE)
  • PHP version: PHP 8.4.21
  • Is this the first time you’ve noticed this situation? Yes
  • When did this problem seem to first start? Nextcloud AIO
  • Installation method: AlO
  • Are you using CloudfIare, mod_security, or similar? No(?)

Summary of the issue you are facing:

In the Docker instance I notice that userID 33 is used (www-data) which is not (by default) available on openSUSE. Here user wwwrun is used normally with user ID 499:

$ getent passwd  | grep www
wwwrun:x:499:498:WWW daemon apache:/var/lib/wwwrun:/usr/sbin/nologin

When logging into the nextcloud-aio-nextcloud container to check the user there I ussue

$ sudo docker exec --user www-data -it $(docker ps | grep nextcloud-aio-nextcloud | awk '{print $1}') bash
$ getent passwd | grep www
www-data:x:33:33::/home/www-data:/sbin/nologin

Steps to replicate (and resolve?) it:

  1. Migrate old (pre-AIO) datadir to new AIO instance (/cloud) and notice (after some time or so) that the data dir has owner 33

  2. Change ownership of complete datadir with chown -R 33:33 . *

  3. To allow somethings outside the docker container with this user also create it as a system user: useradd -u 33 -M -r -U -s /sbin/nologin -c "Docker NC Web User" www-data

  4. getent passwd | grep www
    wwwrun:x:499:498:WWW daemon apache:/var/lib/wwwrun:/usr/sbin/nologin
    www-data:x:33:33:Docker NC Web User:/home/www-data:/sbin/nologin

Questions

Is it sane to manually create a passwordless www-data system user?

Is it really needed at all?

Would it be ok to use a different user (like in my case wwwrun instead of www-data)?

Additional note: afterwards I also ran

$ sudo find /wolk -type f -exec chmod 640 {} \;
$ sudo find /wolk -type d -exec chmod 750 {} \;

2

Is it sane to manually create a passwordless www-data system user?

Depends on what you’re trying to accomplish.

Is it really needed at all?

No, not on the host. It is needed in the container.

Would it be ok to use a different user (like in my case wwwrun instead of www-data)?

On your host or in the container? Keep in mind that the username is mostly (though not entirely) cosmetic. The important part is the uid:gid (33:33).

You could also run rootless as another option.

3

Thanks for taking time to demystify

I also look and sometimes inspect files in my data dir, there I noticed an “unknown user” (no mapping from 33 to username)

I see that, having read something about Docker and used user. Indeed there the user 33 (www-data) does exist.

Yeah, I figured that it would be possible to somehow map the used uid:gid in the container to the wwwrun:www on the host system, so that the internally used (docker) user would map to the legit host user/group. This only to avoid possible “ghost” actions with “ghost” users.

Well that is an interesting option, because when I run the nextcloud-aio-nextcloud container as a normal user or with the sudo command, both reveal that the user in the container still holds root ID:
$ sudo docker exec -it nextcloud-aio-nextcloud id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video)
$ docker exec -it nextcloud-aio-nextcloud id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video)

So this would mean that even if you do not run the nextcloud-aio master container as root, it still runs with root permissions and hence can alter all permissions in the attached volumes. That explains why the /cloud folder showed files with id 33 even when that user did not exist on the host system.

But this also raises an eyebrow on my side: should the mastercontainer really need uid=0?