Mageia forum

I'm trying to rebuild my nextcloud server after a HDD crash: Yes, lesson learned.

I have it installed, and accessible over the LAN: I can log into website with admin and users.
But I get the warning:

Code: Select all

Your data directory is not writable Permissions can usually be fixed by giving the webserver write access to the root directory. See https://docs.nextcloud.com/server/22/go.php?to=admin-dir_permissions.

But that link in the warning doesn't work either....

It shouldn't matter, but the device is raspberry pi2: OS is on an sd card. Data directory is on an external AC powered HDD. I've the HDD mounted via fstab

Code: Select all

UUID=e2d16de6-5947-4d66-918c-3fe545c74d10 /mnt/temp                ext4    defaults,nofail             0 0

Mount confirms this:

Code: Select all

/dev/sda1 on /mnt/temp type ext4 (rw,relatime,seclabel)

The data directory itself is (apologies for the directory layout: It's just how I managed to copy the data off the old drive):

Code: Select all

/mnt/temp/owncloudData/owncloud/data

and it's owned by apache:

Code: Select all

drwxrwx---. 10 apache apache 4096 May  7 17:26 data

As apache user, I can write to the directory:

Code: Select all

su -s /bin/bash apache
bash-5.1$ pwd
/mnt/temp/owncloudData/owncloud
bash-5.1$ cd data
bash-5.1$ ls test*
ls: cannot access 'test*': No such file or directory
bash-5.1$ touch test
bash-5.1$ ls test*
test
bash-5.1$ rm test
bash-5.1$ ls test*
ls: cannot access 'test*': No such file or directory

In the original install I had the data directory as /srv/owncloud/data and that was actually linked from /srv/exthdd/owncloud/data with the external HDD mounted as /srv/exthdd: Not sure why I had that messy link there, but it worked for years: /srv/exthdd/owncloud/data was owned by apache, /srv/exthdd was owned by root.

In the nextcloud config, I have the data directory set as:

Code: Select all

 'datadirectory' => '/mnt/temp/owncloudData/owncloud/data',

Like I say, the web app can see and access the data directory: as a user I can see the files etc:

The nextcloud documentation, and the forums are a bit vague on the data directory, in regards to moving it: It talks about manually messing with the database, but then in the forums that's not neccessary, so it's all conflicting: Given the app can see the data, I don't believe that's the issue.

I'm suspecting it's some ownership issue somewhere, like apache not going across file systems: but again, it can access it. Or a php issue.

I've spent hours on this: I'm totally out of my depth. Any and all advice greatly appreciated: And I'll gladly provide further info it you let me know what you need.

Well... I dug in, and yes, my database has multiple data directory locations.... Almost certain this is the issue I guess. I'll work out how to correct it, then re-evaluate. Stay tuned.

Your permissions setup says that the owner and members of the apache group can write to the data directory. By default, the nextcloud user will be www or www-data. So nextcloud does not have write permission. Either add the nextcloud user to the apache group or (probably better) change the ownership of your nextcloud data directories to match the nextcloud user. Then make sure apache is a member of the same group that is the nextcloud group (again, probably either www or www-data).

Also, I would be very careful about using an RPI or any SD-based distribution for this purpose; nextcloud tends to write a fair amount of log data, and if it writes to that sd card, you won't have much life expectancy out of the SD card...which will take you down again. I have an RPI configured as a pihole DNS, and it writes a LOT. So, I bought an SSD adapter for the RPI and put an SSD on it. just so I would not have that problem. Also, of course, I keep a separate image of the system backed up in case I need it.

Turns out, you need to use the config file that was used to set up that instance: Which I wasn't, once I dropped that in, a lot of the warnings disappeared.
I've got a couple other issues, but I'll start new threads for that.
Thanks.

PS: Jim, I had /boot on the SD card, and / on the HDD. I lost several sd cards, but it was simply a matter of making a new standard fedora sd card, booting that up, finish username, etc set up: then copy /etc/fstab from HDD onto SD card, then adjust for the new /boot UUID, then dracut, and reboot, and then the HDD was / again. Worked well for many years, until the HDD crashed (I check smart regularly, but this one beat me). And I've been in pain ever since trying to get it back