Nextcloud Error Cannot create or write into the data directory /mnt/main/nextcloud/users

[peterge]

Hi, i have /mnt/main/nextcloud/users added for the Nextcloud data directory.
The Host Path for Nextcloud Data Volume is on /mnt/main/nextcloud/data.
I get this error on the nextcloud setup page:
Error
Cannot create or write into the data directory /mnt/main/nextcloud/users

bet its a permission issue. Which permissions are missing on /mnt/main/nextcloud/ users?
Which user do i have to give write rights?
Im running TrueNAS-SCALE-21.08-BETA.1.

 

[sretalla]

2 quick ideas...

1. Open up permissions (777) and see which user owns the files that get created.
2. Nextcloud runs as the www user, so check that in the container and use the ID for that user to assign permissions on the host.

 

[peterge]

1. Open up permissions (777) and see which user owns the files that get created.

truenas# ls -l
total 9
drwxr-xr-x 9 root root 9 Sep 22 10:10 data
drwxrwxrwx 2 root root 2 Sep 22 10:08 users

but the error (Error Cannot create or write into the data directory /mnt/main/nextcloud/users) still keeps coming up when i click finish setup

 

[sretalla]

but the error (Error Cannot create or write into the data directory /mnt/main/nextcloud/users) still keeps coming up when i click finish setup

Is the users directory empty?

 

[peterge]

Is the users directory empty?

yes...
nothing in there:

truenas# pwd
/mnt/main/nextcloud/users
truenas# ls -al
total 1
drwxrwxrwx 2 root root 2 Sep 22 10:08 .
drwxrwxrwx 4 root root 4 Sep 22 10:08 ..

 

[Heracles]

I think that Nextcloud checks for ownership of the directory. There are also more and more things that refuses bad permissions like 777.

Here, you should identify Nextcloud's UID and group and configure your permission accordingly. Here, my Nextcloud is www-data (running the official Docker container outside TrueNAS). As such, the data directory is owned by that user and permissions are 755.

You can check ownership of another Nextcloud directory like its config directory and copy the ownership / permission from that one.

 

[sretalla]

my Nextcloud is www-data

UID?

 

[Heracles]

Yes... My Nextcloud is running as User ID "www-data"....

 

[peterge]

I think that Nextcloud checks for ownership of the directory. There are also more and more things that refuses bad permissions like 777.

Here, you should identify Nextcloud's UID and group and configure your permission accordingly. Here, my Nextcloud is www-data (running the official Docker container outside TrueNAS). As such, the data directory is owned by that user and permissions are 755.

You can check ownership of another Nextcloud directory like its config directory and copy the ownership / permission from that one.

truenas# ls -l data
total 20
drwxr-xr-x 2 www-data root 15 Sep 22 10:10 config
drwxr-xr-x 2 www-data root 2 Sep 22 10:10 custom_apps
drwxr-xr-x 2 root root 2 Sep 22 10:10 data
drwxr-xr-x 14 www-data root 28 Sep 22 10:10 html
drwxr-xr-x 4 root root 4 Sep 22 10:10 root
drwxr-xr-x 3 www-data root 4 Sep 22 10:10 themes
drwxr-xr-x 2 root root 2 Sep 22 10:10 tmp
truenas# chown -R www-data:root users
truenas# ls -l
total 9
drwxr-xr-x 9 root root 9 Sep 22 10:10 data
drwxr-xr-x 2 www-data root 2 Sep 22 10:08 users

its still showing that error. User and Group are the same as in data, and itsEven after a restart of the nextcloud containers...

 

[sretalla]

Yes... My Nextcloud is running as User ID "www-data"....

Right... but what's the UID of that user... 1001? 900? without that, you can't fix things on the host, which may either not have that user or have a different UID.

id <username> (in the container) should give it to you.

If not, what does the ls -l show (if it's www-data, then id www-data on the host will cover it, it comes back as 33 for me on a scale host)

 

[Heracles]

As a mentioned, I do not run the TrueNAS' jailed version of Nextcloud but the official Docker container that runs from a Docker host that is also not in TrueNAS. That one uses www-data / 33 so I replicated that in TrueNAS : i created the user with the same name (www-data) and same number (33).

 

[peterge]

Right... but what's the UID of that user... 1001? 900? without that, you can't fix things on the host, which may either not have that user or have a different UID.

id <username> (in the container) should give it to you.

If not, what does the ls -l show (if it's www-data, then id www-data on the host will cover it, it comes back as 33 for me on a scale host)

Pod Shell nextcloud:
root@nextcloud-postgres-59585ccb7f-cwr5x:/# id www-data
uid=33(www-data) gid=33(www-data) groups=33(www-data)

system shell:
truenas# id www-data
uid=33(www-data) gid=33(www-data) groups=33(www-data)

 

[truecharts]

It might also be worthwhile to note if you're actually using the Official or TrueCharts version of the Nextcloud container.
There are some quite significant differences when it comes to storage.

 

[peterge]

I have "fixed" the "problem". And it was just a stupid error which me and no one else noticed.
I wrote I entered "/mnt/main/nextcloud/users" for the "Nextcloud data directory".
But the "Nextcloud data directory" seems to expect the path where the data should be stored from INSIDE the container. Not from its host perspective.
I reinstalled and left it on the dafult /var/www/html/data. Everything worked fine.
Maybe it would be more helpful if this is explained in the tooltip during configuring the container.

 

[pk2]

@peterge -- after completing Nextcloud setup, how did you direct it to store data in your other data directory? What is the /var/www/html/data directory storing?

 

[peterge]

@peterge -- after completing Nextcloud setup, how did you direct it to store data in your other data directory? What is the /var/www/html/data directory storing?

This is what I left in Nextclouds config:

I checked with Pod Shell and there is no /var/www/html/data.

This is how I store data in /mnt/main/nextcloud.
I don't know why its /var/www/html/data, it was set as default and I did not change it...

Does this answer your question? I can provide you more info, if you tell me what you need ^

 

[taltamir]

I am running into the same issue.
I am installing the official docker app of nextcloud. (and I gotta say it is way better than the truenas core version where I had to putty into it to edit files via nano to get it to work).

The first bit of trouble was that it wouldn't create the specified dataset/folder. I wanted it in tank/nextcloud/data
it failed to install with an error about not being able to access those directories.
so I went ahead and used zfs create tank/nextcloud and then used mkdir to create /data inside it.

then I was able to install it. This started out things on a bad footing as the mounted dataset had root as its owner since I was logged into the webgui for truenas as root.
(incidentally, I can't log into truenas with my own personal sudo permitted account for some reason. I can SSH into truenas and do sudo with my personal account, but I can't use the webgui)

Sure it works if I don't change the locations, but I really want to change them.

 

[taltamir]

So, I somehow managed to make it worse at first when messing with permissions. Changing ownership from root just made it more broken. Where instead of asking me to create an admin account and then failing to write, it was giving me an error message whose exact details I forgot.

I tried uninstalling then reinstalling, no go.

I decided to try changing how I go about things.
I deleted the dataset /nextcloud and then recreated it. instead of putting folders in it for the 3 different things I wanted to map, I created 3 child datasets called data, postgres, and backup. Backup had ownership set to username backup
the other two had ownership set to username www-data (found in drop down menu).

Gave me a bad gateway error. So... even worse than before, at least the previous error was from the app's gui.

I decided to take a step back and only map the data directory. and leave the origin point untouched.
Still giving a bad gateway error.
Tried restarting the whole server instead of only the docker... and it worked.
pretty odd that I had to reboot the entire server.

but anyways, it works when data (alone) is mapped to a dataset which has ownership given to user and group www-data
I will continue fiddling with it later to see if I can get the other two mapping to work.
The initial setup should really do this adjustment automatically

 

[taltamir]

Ok, I tracked down the problem with relocating the database.

When I edit the app/container settings to specify I want to use a host path for postgress data volume, it changes the permissions on that dataset (or presumably folder if I wasn't using one. But I am using a dataset).
It changes the owner from www-data to user-999, which when I open the ACL viewer GUI shows up as a blank nonexistent user.
It also changes the permissions to remove all permissions from [group] and [other], and gives sole full permissions to user-999. so... chmod 700 if I am not mistaken.

As a result of doing this, the app crashes on launch and gives me

Internal Server Error

The server encountered an internal error and was unable to complete your request.
Please contact the server administrator if this error reappears multiple times, please include the technical details below in your report.
More details can be found in the server log.

While I suspect this won't work, I am reminded of how earlier I had to restart the whole server instead of just the docker container in order to get it to work with an altered user data location.

So. in conclusion the official nextcloud app install has the following bugs:
1. it does not create datasets or folders when you specify a path that does not yet exist. You must manually create them before install.
2. changing the user data directory via the GUI setup page fails to set permissions. resulting in nonfunctional nextcloud until you manually change permissions on the target folder or dataset to belong to user www-data
3. changing the postgres data directory via the GUI setup incorrectly changes the permissions to a non existent user-999. it also changes permissions to 700 which... is probably correct. so long as it can be fixed to also set the user to the correct username it should work fine.

As for backups. Not sure if it works or not. It requires further testing which I can't do right now due to my sudden HDD death

edit: well, it turns out it was just a loose cable. tightening it showed it back up as a seperate drive.
until a reboot at which point it was showed as degraded... until a zpool clear command which resilvered 64M in a fraction of a second. hopefully this was a one time event

 

[taltamir]

well this is weird. disabling the postgress data remapping meant going back to a previously working state. However, it says

Your data directory is invalid. Ensure there is a file called ".ocdata" in the root of the data directory. 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/server/24/go.php?to=admin-dir_permissions.

even though it worked before on those exact settings... maybe another restart is needed as I have changed the container settings. which is clearly another bug, I should not have to restart the entire system, only the individual container. and yet I do have to restart the whole system?

edit: no, restart did not fix it.

edit2: going back to the dataset and re-applying the same current permissions recursively... gives the same message but now through a functional GUI. where before it was a plain text message. restarting the whole server... still not fixed. weird, it was working before on these exact same settings.

... tried setting it to 777. Still not working.

new attempt:
1. uninstall nextcloud (deleting the docker app).
2. set permissions back to 770 on /data
3. reinstall nextcloud (latest official charts) from available applications
...

Internal Server Error

The server encountered an internal error and was unable to complete your request.
Please contact the server administrator if this error reappears multiple times, please include the technical details below in your report.
More details can be found in the server log.

edit3:
ok I figured something out. You can change the internal docker data directory after it is all setup, but not before. If you change it before it fails for various reasons. So this is yet one more issue to add to the list of problems with this install.