At some point in the past few weeks, I started getting this error: Your data directory is invalid. See attached.
I have a snap who’s data directory is an external location.
I assume an updated happened which has caused this problem. My snap config has been working just fine for ~2 years. So I’m very rusty on trying to figure this out.
I’m running Debian 10.8.
Any help would be greatly appreciated!
Check that the data directory is actually accessible by logging into the machine. Are the files intact, is the external disk functioning? The disk may have become unmounted, the cable connecting it may have come loose, or the disk itself may have experienced a hardware fault.
When I first set up nextcloud a month or so ago, Nextcloud Snap would sometimes delete the .ocdata file – If you’ve confirmed that the data directly is okay (not corrupted, deleted, whatever), an easy fix is to cd into the data directory and touch .ocdata. This command will create a new blank .ocdata file.
All my files were completely accessible from the CLI and the permissions were set correctly just as they originally were. I ended up rolling back the VM two weeks to get a previously working version.
This morning I find it’s broken again. Could the Canonical snap be auto updating and causing the issue?
I get the following info in dmesg:
[243252.381543] audit: type=1400 audit(1617029267.978:762): apparmor=“DENIED” operation=“capable” profile=“snap.nextcloud.nextcloud-cron” pid=2695 comm=“php” capability=2 capname=“dac_read_search”
[243252.501249] audit: type=1400 audit(1617029268.094:763): apparmor=“DENIED” operation=“capable” profile=“snap.nextcloud.nextcloud-cron” pid=2695 comm=“php” capability=2 capname=“dac_read_search”
[243724.442718] audit: type=1400 audit(1617029740.046:764): apparmor=“DENIED” operation=“capable” profile=“snap.nextcloud.php-fpm” pid=3351 comm=“php-fpm” capability=2 capname=“dac_read_search”
[243730.427324] audit: type=1400 audit(1617029746.030:765): apparmor=“DENIED” operation=“capable” profile=“snap.nextcloud.php-fpm” pid=3351 comm=“php-fpm” capability=2 capname=“dac_read_search”
[243730.459216] audit: type=1400 audit(1617029746.062:766): apparmor=“DENIED” operation=“capable” profile=“snap.nextcloud.php-fpm” pid=3351 comm=“php-fpm” capability=2 capname=“dac_read_search”
[244152.889451] audit: type=1400 audit(1617030168.498:767): apparmor=“DENIED” operation=“capable” profile=“snap.nextcloud.nextcloud-cron” pid=4088 comm=“php” capability=2 capname=“dac_read_search”
[244152.987839] audit: type=1400 audit(1617030168.598:768): apparmor=“DENIED” operation=“capable” profile=“snap.nextcloud.nextcloud-cron” pid=4088 comm=“php” capability=2 capname=“dac_read_search”
[244165.078599] audit: type=1400 audit(1617030180.690:769): apparmor=“DENIED” operation=“capable” profile=“snap.nextcloud.php-fpm” pid=4111 comm=“php-fpm” capability=2 capname=“dac_read_search”
The web page shows now shows the following:
I reverted back to a working snapshot of my VM this morning and I found the following:
I forgot to remove the /etc/apt/apt.conf.d/50unattended-upgrades file on Friday.
So although I rolled back to a earlier VM backup, the VM proceeded to update itself over the weekend.
After the snapshot restore, I ran apt update and apt list --upgradable I see the below list. One of these updates is causing apparmor issues with the Nextcloud snap.
apt list --upgradable
Listing… Done
avahi-daemon/stable 0.7-4+deb10u1 amd64 [upgradable from: 0.7-4+b1]
base-files/stable 10.3+deb10u9 amd64 [upgradable from: 10.3+deb10u8]
debian-archive-keyring/stable 2019.1+deb10u1 all [upgradable from: 2019.1]
exim4-base/stable 4.92-8+deb10u5 amd64 [upgradable from: 4.92-8+deb10u4]
exim4-config/stable 4.92-8+deb10u5 all [upgradable from: 4.92-8+deb10u4]
exim4-daemon-light/stable 4.92-8+deb10u5 amd64 [upgradable from: 4.92-8+deb10u4]
groff-base/stable 1.22.4-3+deb10u1 amd64 [upgradable from: 1.22.4-3]
iputils-ping/stable 3:20180629-2+deb10u2 amd64 [upgradable from: 3:20180629-2+deb10u1]
libavahi-client3/stable 0.7-4+deb10u1 amd64 [upgradable from: 0.7-4+b1]
libavahi-common-data/stable 0.7-4+deb10u1 amd64 [upgradable from: 0.7-4+b1]
libavahi-common3/stable 0.7-4+deb10u1 amd64 [upgradable from: 0.7-4+b1]
libavahi-core7/stable 0.7-4+deb10u1 amd64 [upgradable from: 0.7-4+b1]
libavahi-glib1/stable 0.7-4+deb10u1 amd64 [upgradable from: 0.7-4+b1]
libbsd0/stable 0.9.1-2+deb10u1 amd64 [upgradable from: 0.9.1-2]
libnss-systemd/stable 241-7~deb10u7 amd64 [upgradable from: 241-7~deb10u6]
libpam-systemd/stable 241-7~deb10u7 amd64 [upgradable from: 241-7~deb10u6]
libpython3.7-minimal/stable 3.7.3-2+deb10u3 amd64 [upgradable from: 3.7.3-2+deb10u2]
libpython3.7-stdlib/stable 3.7.3-2+deb10u3 amd64 [upgradable from: 3.7.3-2+deb10u2]
libpython3.7/stable 3.7.3-2+deb10u3 amd64 [upgradable from: 3.7.3-2+deb10u2]
libssl1.1/stable 1.1.1d-0+deb10u6 amd64 [upgradable from: 1.1.1d-0+deb10u5]
libsystemd0/stable 241-7~deb10u7 amd64 [upgradable from: 241-7~deb10u6]
libtiff5/stable,stable 4.1.0+git191117-2~deb10u2 amd64 [upgradable from: 4.1.0+git191117-2~deb10u1]
libudev1/stable 241-7~deb10u7 amd64 [upgradable from: 241-7~deb10u6]
linux-image-amd64/stable 4.19+105+deb10u11 amd64 [upgradable from: 4.19+105+deb10u9]
openssl/stable 1.1.1d-0+deb10u6 amd64 [upgradable from: 1.1.1d-0+deb10u5]
python3.7-minimal/stable 3.7.3-2+deb10u3 amd64 [upgradable from: 3.7.3-2+deb10u2]
python3.7/stable 3.7.3-2+deb10u3 amd64 [upgradable from: 3.7.3-2+deb10u2]
systemd-sysv/stable 241-7~deb10u7 amd64 [upgradable from: 241-7~deb10u6]
systemd/stable 241-7~deb10u7 amd64 [upgradable from: 241-7~deb10u6]
udev/stable 241-7~deb10u7 amd64 [upgradable from: 241-7~deb10u6]
xterm/stable 344-1+deb10u1 amd64 [upgradable from: 344-1]
Any ideas on what combination would be causing this issue in Debian 10.8?
Update:
snap 2.49 and prior, the external/removable data location could have www-data:www-data ownership and work correctly.
Upon updating to snap 2.49.1 the external location must have root:www-data ownership.