Docker + Nextcloud + External storage

Quote from Alomon

Hi,

Now I'm facing anothher issue. I would like to access my Nextcloud instance via (for example) https://www.domain.duckdns.org:2222.

For that, I've forwarded port 2222 to port 443 on my router, as Nextcloud and letsencrypt are accessed on port 443. But it doesn't seem to be sufficient, I've got a timeout error when trying to access Nextcloud on port 2222 and even from my local network.

Where am I wrong? Do I have to change some settings somewhere on nextcloud and/or letsencrypt? Or even to rebuild the containers?

Thanks

Nextcloud has its own auto redirects for security purposes and you'll have to modify those in it's config file. You may have to do other stuff on the nginx side but I'm not sure.

All of that automation was done for port 443, ymmv with a custom port

My guess is, it's due to curl when trying to connect to the domain, trying to go out the wan and try to come back in through the router and into the letsencrypt container.

Assuming the cron tasks are running inside the nextcloud container, see if you can curl "https://localhost/remote.php/dav/calendars/<username>/personal?export" instead, so it tries to connect directly

Hey Alomon,

i also want to install nextcloud as easy as its possible I have tried it over the linuxserver.io repo but this will not work for me ... I hope may be you can help me. At the end i want mainly use KODI to watch tv and in the background i would like to run nextcloud. I have an raspbery 3b+ - and if that is not enough i will get a raspberry pi4 with 8gb.

Can you maybe give me some informations and what is the easiest or best way to install nextcloud on KODI (LibreELEC)????

Quote from Alomon

Hi,

Now I think I've got it installed, I used CLI to be able to monitor everything:

Code

docker create \
  --name=nextcloud \
  --net=lsio \
  -e PUID=65534 \
  -e PGID=100 \
  -e TZ=Europe/London \
  -v /storage/.kodi/userdata/addon_data/docker.linuxserver.nextcloud/config:/config \
  -v /storage/.kodi/userdata/docker.linuxserver.nextcloud/data:/data \
  --restart unless-stopped \
  linuxserver/nextcloud

Code

docker create \
  --name=mariadb \
  --net=lsio \
  -e PUID=65534 \
  -e PGID=100 \
  -e MYSQL_ROOT_PASSWORD= _SQL_PASS_\
  -e TZ=Europe/London \
  -e MYSQL_DATABASE=nc \
  -e MYSQL_USER= _SQL_USER_ \
  -e MYSQL_PASSWORD=_SQL_USER_PASS_ \
  -p 3306:3306 \
  -v /storage/.kodi/userdata/addon_data/docker.linuxserver.mariadb/config:/config \
  --restart unless-stopped \
  linuxserver/mariadb

Display More

Code

docker create \
  --name=letsencrypt \
  --cap-add=NET_ADMIN \
  --net=lsio \
  -e PUID=65534 \
  -e PGID=100 \
  -e TZ=Europe/London \
  -e URL=_MY_DOMAIN_.duckdns.org \
  -e SUBDOMAINS=nextcloud \
  -e VALIDATION=duckdns \
  -e DUCKDNSTOKEN=_MY_TOKEN_ \
  -e EMAIL=_MY_MAIL_ \
  -e DHLEVEL=2048 \
  -e STAGING=false \
  -p 443:443 \
  -v /storage/.kodi/userdata/addon_data/docker.linuxserver.letsencrypt/config:/config \
  --restart unless-stopped \
  linuxserver/letsencrypt

Display More

Then:

Code

docker start mariadb
docker start nextcloud
docker start letsencrypt

I used a custom dhparams to speed things up as explained here. I also had to edit nextcloud.subdomain.conf file with proxy_max_temp_file_size 1024m; as explained there. Then docker restart letsencrypt.

I can now access to my Nextcloud instance via https://nextcloud._MY_DOMAIN_.duckdns.org. Howerver, my browsers still trigger a safety alert regarding the certificate because the certificate is for _MY_DOMAIN_.duckdns.org and not for nextcloud._MY_DOMAIN_.duckdns.org.

I tried as well to install letsencrypt with wildcard as SUBDOMAINS but got the same error because the certificate was for *._MY_DOMAIN_.duckdns.org.

This seems to provide other applications to access Nextcloud (in my case, Home Assistant).

Is there a solution fot that?

Thanks again

Display More

I have installed docker nexcloud twice, the first time with nginx and mariadb, and the second time with apache and mariadb. I have LE installed on an Intel i5 mini PC with 8GB RAM with plenty of power for the requirements. In spite of everything, nexcloud works with an unacceptable slowness. I may not have applied enough tweaks but I think nextcloud is not made for home use, I will continue to use syncthing because it works great with any processor!

It should be fine because the ssd should be mounted before docker starts. Rpi4 has enough power for an external ssd. Not sure about rpi3, but you can use a powered sata adapter worst case.

Keep in mind that rpi4 can also boot from an external ssd, so no need to deal with the sd card at all. A sata adapter with uasp does wonders for overall speed.

I resume this old post because I was in the same situation:

NTFS usb disk used with nextcloud docker (I know this is NOT the ideal solution but I was forced to use this filesystem)

udevil mounts automatically with fmask=0133 and You can't change this behaviour because /etc/udevil/udevil.conf is in the read only part of the fs

check_data_directory_permissions => false on nextcloud config is not the solution because user nobody doesn't have rights to write into the disk

my solution was to make a udev rule to exclude standard udevil mount for only my particular disk and mount it using my parameters

steps to reproduce it:

1) copy real udev to the storage part

cp /lib/udev/rules.d/95-udevil-mount.rules /storage/.config/udev.rules.d/

2) modify this rule (in my case I wanted to do something different for every disk with label starting with string "Max")

# dont run in "installer" mode
IMPORT{cmdline}="installer"
ENV{installer}=="1", GOTO="exit"

# check for blockdevices, /dev/sd*, /dev/sr*, /dev/mmc*, and /dev/nvme*
SUBSYSTEM!="block", KERNEL!="sd*|sr*|mmc*|nvme*", GOTO="exit"

# check for special partitions we dont want mount
IMPORT{builtin}="blkid"
ENV{ID_FS_LABEL}=="EFI|BOOT|Recovery|RECOVERY|SETTINGS|boot|root0|share0", GOTO="exit"

# /dev/sd*, /dev/mmc*, and /dev/nvme* with partitions/disk and filesystems only, and /dev/sr* disks only
KERNEL=="sd*|mmc*|nvme*", ENV{DEVTYPE}=="partition|disk", ENV{ID_FS_USAGE}=="filesystem",ENV{ID_FS_LABEL}=="Max*" GOTO="harddisk_special"
KERNEL=="sd*|mmc*|nvme*", ENV{DEVTYPE}=="partition|disk", ENV{ID_FS_USAGE}=="filesystem" GOTO="harddisk"
KERNEL=="sr*", ENV{DEVTYPE}=="disk", GOTO="optical"
GOTO="exit"

# mount or umount for hdds special rule ntfs rw with nouser
LABEL="harddisk_special"
ACTION=="add", PROGRAM="/usr/bin/sh -c '/usr/bin/grep -E ^/dev/%k\  /proc/mounts || true'", RESULT=="", RUN+="/usr/bin/systemctl restart udevil-mount2@/dev/%k.service"
ACTION=="remove", RUN+="/usr/bin/systemctl stop udevil-mount2@/dev/%k.service"
GOTO="exit"

# mount or umount for hdds
LABEL="harddisk"
ACTION=="add", PROGRAM="/usr/bin/sh -c '/usr/bin/grep -E ^/dev/%k\  /proc/mounts || true'", RESULT=="", RUN+="/usr/bin/systemctl restart udevil-mount@/dev/%k.service"
ACTION=="remove", RUN+="/usr/bin/systemctl stop udevil-mount@/dev/%k.service"
GOTO="exit"

# mount or umount for opticals
LABEL="optical"
ACTION=="add|change", RUN+="/usr/bin/systemctl restart udevil-mount@/dev/%k.service"
GOTO="exit"

# Exit
LABEL="exit"

3) make a copy of service udevil-mount

cp /usr/lib/systemd/system/[email protected] /storage/.config/system.d/udevil-mount2@.
service

4) modify service as follow

[Unit]
Description=Udevil mount service

[Service]
Type=oneshot
ExecStart=-/storage/bin/mount_special_disk %I
ExecStop=-/usr/bin/udevil --umount %I
ExecStartPost=-/usr/lib/samba/samba-autoshare
ExecStopPost=-/usr/lib/samba/samba-autoshare
RemainAfterExit=yes

5) create /storage/bin/mount_special_disk

#!/bin/sh
disklabel=`/usr/sbin/blkid -o value -s LABEL $1`
mkdir -p /media/$disklabel
/usr/bin/mount -t ntfs -o nosuid,noexec,nodev,noatime,big_writes,fmask=0022,uid=65534,gid=100,utf8,permission $1 /media/$disklabel

6) make script executable

chmod a+x /storage/bin/mount_special_disk

and that's all; every time a disk with label starting with "Max" is attached (I have 2 disks Max1 and Max2 all of them NTFS) it will be automounted in the same place of before, but with modified options so Nexcloud (or any other docker instance) can write to

those scripts are far from ideal but they works, at least for my puposes...

Quote from librero

The Nextcloud data directory must have 0770 (rwxrwx---) permisions as shown in that same error page you got. What it doesn't say there is that the data directory also must be owned by nobody.users (65534.100) so Netxcloud would be able to access it.

By default Libreelec (udevil) automounts the usb storage as 777 (rwxrwxrwx) root.root but Nextcloud runs as user nobody.

The external storage is automounted with udevil and whose config file is /etc/udevil/udevil.conf that is located in the read only part of the file system and doesn't seem to be possible to override the default_options_ntfs to change the user and group it automounts the hdd with.

default_options_ntfs      = nosuid, noexec, nodev, noatime, big_writes, fmask=0133, uid=$UID, gid=$GID, utf8

to:

default_options_ntfs      = nosuid, noexec, nodev, noatime, big_writes, fmask=0133, uid=65534, gid=100, utf8

You could try to disable that permission check at boot in:

/storage/.kodi/userdata/addon_data/docker.linuxserver.nextcloud/config/www/nextcloud/config/config.php with:

'check_data_directory_permissions' => false,

but that won't work because of the fmask=0133 that makes all files readonly for non-root users.

Anyway I've not tried changing udevil.conf and I'm not sure if this would be enough for Nextcloud to have the whole data directory in an NTFS (or exFAT) drive since neither support unix type permisions. Also won't recommend messing with udevil config unless you know what you are doing.

The other (dirty) option to try would be to unmount and remount the device with the required permissions. A background script launched from /storage/.config/autostart.sh could periodically check if these are correct and unmount and remount when required, but again not sure if will work with NTFS or exFAT..

Alternatively you also can easily share an NTFS formatted disk in Nextcloud just sharing it via the own Libreelec samba server and adding it via the external storage app, with a similar result to using the -v /var/media/My\ Book:/My\ Book parameter in the addon's additional config page but still the users folders will be kept inside the container's original data directory, which may not be what you want.

Display More