NextCloud AIO - Permission denied?

1. offizieller Beitrag

    Hallo,

    nach der Installation von NextCloud AIO via Docker Compose Plugin erhalte ich diesen Fehler:

    "Forbidden - You don't have permission to access this resource"



    Ich habe diese yaml-File als Vorlage genommen: https://github.com/nextcloud/a…ne/blob/main/compose.yaml


    Und minimal adaptiert: i) Den Port 8085 auf 8080 und ii) den Pfad für den Datenfolder.


    Leider kann ich die NextCloud-Installation nicht erreichen, ich erhalte stets obigen Fehler.

    Auch wenn ich Port oder Pfade ändere, sogar wenn ich die Option für einen getrennten Dateipfad ganz weglasse.

    Woran könnte das liegen?


    Disclaimer: U.U. habe die Berechtigungen in meiner omv durch Verzweiflungstat auf der Kommandozeile durcheinander gebracht, siehe Hintergrundgeschichte…


    Kontext&Hintergrund:

    Bis Mitte Februar hatte ich eine NextCloud im Admin-Modus bei owncube. Nachdem die Firma owncube mit (sehr) kurzer Vorlaufzeit eingestellt hat, wollte ich den Betrieb einer eigenen NextCloud-Instanz versuchen.

    Diese ist ausschließlich für den privaten Gebrauch gedacht (zum Syncen von Dateien und Kalender zwischen den Familienmitgliedern und als Dateiablage für einen kleinen Verein). Seit ca. 1,5 Jahren habe ich omv auf einem Lenovo ThinkCentre M92p laufen. Das ist mein bisher einziger Kontakt mit der Linuxwelt. Auf omv habe ich AdGuard und Jellyfin laufen, ansonsten dient das Gerät als NAS. Nun sollte es auch meine eigene NextCloud beheimaten.


    Nach einigem Googlen habe ich zuerst die Installation von NextCloud mit der Docker Plugin versucht, grundsätzlich dieser Anleitung folgend:


    https://forum.openmediavault.o…omv-and-docker-compose%2F


    Nachdem ich hier keinen Erfolg hatte, habe ich die AIO-Variante versucht. Da habe ich die Anleitung von NextCloud genommen: https://nextcloud.com/blog/how…loud-all-in-one-on-linux/


    (Die AIO-Installation funktionierte grundsätzlich, mir gelang es hier aber nicht den Datenfolder außerhalb des Docker-Laufwerks zu haben. Daher habe ich das zu Beginn erwähnt YAML versucht.)


    Meine Befürchtung ist, dass ich mir die Rechte bei meinem ersten Versuch zerschossen habe.

    Bei Versuch 1 konnte ich die Container starten und die NextCloud-Oberfläche erreichen.

    Gleich nach dem ersten Schritt (Auswahl der Datenbank und Installation) erhielt ich aber den Fehler:

    „Your data directory is readable by other users. Please change the permissions to 0770 so that the directory cannot be listed by other users”


    Bei der Suche nach Hilfe im Netz bin ich auf den Hinweis gestoßen, die Rechte über ssh anzupassen.

    Das habe ich mit diesen Befehlen versucht:


    sudo chmod 0770 /srv/dev-disk-by-uuid-01DA010251B527C0/nextcloud/

    sudo chmod -R 0770 /srv/dev-disk-by-uuid-01DA010251B527C0/nextcloud/data

    sudo chown -R 33:0 /srv/dev-disk-by-uuid-01DA010251B527C0/nextcloud/data

    sudo chmod -R 750 /srv/dev-disk-by-uuid-01DA010251B527C0/nextcloud/data


    Das hat nichts geholfen. Mein Hauptproblem ist, dass ich diese Befehle nicht verstehe.

    Es ist mir klar, dass es keine besonders gute Idee ist, Befehle abzuwerfen ohne sie hinreichend zu verstehend, faktisch handelt man aus Hilflosigkeit eben nicht immer vernünftig...


    Bin um Hinweise dankbar, ich würde gerne meine NextCloud-Installation zum Laufen bringen.

  • crashtest

    Hat das Thema freigeschaltet.
    Zitat von debreziner

    /srv/dev-disk-by-uuid-01DA010251B527C0

    Using drives with Windows FS on Linux/docker won't work un


    You need a drive formatted with a Linux FS

    • Offizieller Beitrag
    Zitat von Soma

    Using drives with Windows FS

    Yeah, I missed that, I didn't look hard enough. :thumbup:

    Zitat von debreziner

    ... but: how did you know that the drive I'd like to use for data is ntfs format?

    Magic...


    And the fact that the UUID has that sequence with ALL caps.

    On Linux FS, the UUID looks like this:


    Code
    /srv/dev-disk-by-uuid-29b1084b-a7f3-432d-99b9-1f71e9a2c383

    Hi,

    just a short update, ten days later: I was away from home a couple of days, then I tried again with a ext4 drive.

    Installation of NextCloud AIO was fast and smooth. My NextCloud has been up and (mostly) working for two days by now.

    Unfortunately I experienced twice the following error: "Your data directory is not writable. Permissions can usually be fixed by giving the web server write access to the root directory. See https://docs.nextcloud.com/ser…?to=admin-dir_permissions"


    After rebooting omv, things work again as expected. Not sure what is going wrong here. Quick googling brought up there might be a hardware failure looming, hopefully not.


    ++++

    As a sidenote: What took me really a long time was moving data and reformatting drives.

    This is off-topic here, I just mention this if anyone stumbles upon the threadopening issue and has also to work his way through what for me was a data migration week of hell :)


    My task was to move data

    1. from a NTFS-formatted, 4TB Crucial P3 SSD, working as external drive in an USB-case
    2. to a NTFS-formatted 3TB HGST HDD, working as external drive in an USB-case
    3. reformat the Crucial SSD as ext4
    4. move data back from the NTFS-HDD to the ext4-SSD I whished to use as datadir in NextCloud

    This part was pretty easy, the SSD being an SMB-Share from omv and having the HDD locally connected via usb dock.

    I mirrored the drive using robocopy in Win 11.


    After that I took almost every wrong turn a Linux noob might take.

    • I removed the SSD from omv without removing the smb-share, the shared folder and other services referring to the ssd.

    Of course this was bs, you first have to make sure the drive is not used/referenced by any service in omv anymore.

    • I tried formatting the SSD on Win 11 using Mint Tool. This seemed to work, but did not. When I connected the drive to omv, it showed up as disk, but I could not use it as filesystem. Random errors kept coming up. I even tried deleting the disk in omv, this led to an error to. As I found out after many trial&errors, the partition table was not correct.

    Using parted on CLI in a putty session brought the SSD back on track, I could write a new partition table and format the drive as ext4 and use it in omv.

    The next step was moving data back from the HDD to SSD. I tried robocopy, which gave permission errors.

    I then tried plugging both drives in omv and using both as smb-fileshare in omv, so I could try copying in Windows file explorer (...hm...sorry.).

    Maybe not surprisingly, this did not work as expected. It copied for a while, then errors kept coming.

    After that, I tried using WinSCP. This might have worked, but I ended up not having enough free space on my windows drive for the local cache so it broke down somewhere in the middle of the copying-process.

    After cursing a lot, especially owncube (my former NextCloud-hoster) for having stopped service, reading the NextCloud and omv documentation for backups I saw the light: rsync!


    Just one command line and the thing started copying reliably data back from the hdd to the ssd.

    It just stopped twice (as mentioned before) because the SSD seemed to not be available anymore.

    After rebooting I just started the task again and everything was fine.


    So my key take aways are:

    • Learn how to remove drives properly from omv (i.e. checking services and removing step by step any reference to the drive)
    • Learn how to use parted
    • Use ext4 in a docker app and for docker data (!)
    • Knowing&loving rsync

    Thanks Soma for finding the issue so promptly!

    • Offizieller Beitrag

    After reading everything you did, just a word of advice, although it may be a little late...


    Nextcloud takes over the data folders. This means that this data can only be modified from Nextcloud. Therefore, sharing that folder with a service other than Nextcloud, for example samba, is useless since you cannot modify the data. You are stuck on Nextcloud.


    The solution is to install the external storage plugin in Nextcloud. Then you can mount folders within Nextcloud and use that data in Nextcloud as if it were from Nextcloud, but with the difference that you can also modify it from other services without problems.

    Thanks, chente. At this point, I can still create a new NextCloud Docker without greater downsides.

    This is good advice. Actually, I was wondering, where NC-data was gone since I saw decreasing free space on the drive but couldn't find the datadir folder in WinSCP...

    Ok, so I will take a look at the external storage plugin, just to check whether there are some implications.

    The first I can think of is that the data will not be backed up with borg, I think...

    Zitat von chente

    Nextcloud takes over the data folders. This means that this data can only be modified from Nextcloud. Therefore, sharing that folder with a service other than Nextcloud, for example samba, is useless since you cannot modify the data. You are stuck on Nextcloud.


    The solution is to install the external storage plugin in Nextcloud. Then you can mount folders within Nextcloud and use that data in Nextcloud as if it were from Nextcloud, but with the difference that you can also modify it from other services without problems.

    This is not completely true. It is possible to samba share nextcloud directories if the samba user and the nextcloud user and permissions are the same. This can be achieved by adding something like this to the samba share extra options, where the masks, modes and forced user and group match the nextcloud user and permissions:

    Code
    create mask = 6777
directory mask = 6777
force create mode = 6777
force directory mode = 6777
force user = www-data
force group = www-data

    However, it does not get around the issue of changes on the filesystem not being reflected in the nextcloud database intil a file scan is performed by a sudo -u <nextcloud web user> php /path/to/nextcloud/web/root occ files:scan <nextcloud user to scan> being issued from within the nextcloud container or from a cron scheduled scan in the container.


    Your solution to use the external storage plugin is definitely easier for most users here.


    My nextcloud is run from an LXC with a custom/manual install script that I have made, not a docker container, and I have configured OliveTin on it ( https://www.olivetin.app ) to give another webpage that I can do a one-click scan to do this. It is supposed to be possible to have OliveTin set up as a docker too and issue any CLI type of commands that may be needed, which could trigger a scan in the nextcloud container if you are running like that, but to be honest, I have not actually attempted a docker install of it and as is standard practice with OMV, I would not want to try to install it natively on OMV.

    • Offizieller Beitrag
    Zitat von BernH

    This is not completely true. It is possible to samba share nextcloud directories if the samba user and the nextcloud user and permissions are the same. This can be achieved by adding something like this to the samba share extra options, where the masks, modes and forced user and group match the nextcloud user and permissions:


    However, it does not get around the issue of changes on the filesystem not being reflected in the nextcloud database intil a file scan is performed by a sudo -u <nextcloud web user> php /path/to/nextcloud/web/root occ files:scan <nextcloud user to scan> being issued from within the nextcloud container or from a cron scheduled scan in the container.


    This seems more like a way to modify files from Samba. But, as you say, limited to a specific user, with specific permissions and with the problem of subsequently updating the Nextcloud database. In short, you still have the problem. The external storage plugin solves this.

    Zitat von debreziner

    The first I can think of is that the data will not be backed up with borg, I think...

    Indeed, this data will not be backed up with borg. I use other means to safeguard my data. For me Nextcloud is not a place to store data. I use it as a service to access my data from the internet. The Nextcloud data folder in my case only stores phone numbers, calendars and little else. It takes up very little space. This allows me to place it on the same disk where docker is, a disk with little storage capacity but high access speed.

    Hi, thanks for the input regarding samba, the external storage solution seems actually easier.

    But... could you guys tell from the following error if I have any problem in the software configuration or if I running straight into hardware failure?

    NC and rsync stopped working suddenly and I'm a bit concerned I'm moving most of my data on a device going to break?!


    This is what I get in the omv notifications, /dev/sdd1 being the Crucial SSD:

    • Offizieller Beitrag

    You should open a new thread with this problem and provide all the relevant information so that someone can help. Like what you did before the error, etc.

    i have the same issue, restore Nextcloud-AIO 27.1.2 from Raspberry Pi via Borg-Backup to amd64 (Debian 12) => Proxmox-Container => new installation.

    Error-Message :

    start.sh: line 51: /nextcloud/custom_apps/notify_push/bin/x86_64/notify_push: Permission denied

    Any idea … ?

    • Offizieller Beitrag
    Zitat von Rockit

    i have the same issue, restore Nextcloud-AIO 27.1.2 from Raspberry Pi via Borg-Backup to amd64 (Debian 12) => Proxmox-Container => new installation.

    Error-Message :

    start.sh: line 51: /nextcloud/custom_apps/notify_push/bin/x86_64/notify_push: Permission denied

    Any idea … ?

    Is it really the same problem? Do you have an NTFS file system? If not, you should open a new thread explaining your problem and all the background.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden