Integrity check failed - Invalid hash .user.ini

Disclaimer - I’m using the docker install from ownyourbits. I didn’t put this in the appliances category because I don’t think this is an issue with that, but I wanted to make clear that this is my environment.

A while ago I had an issue with my nextcloud instance and posted this thread. To summarize - I’m pretty sure a power outage wrecked my database, but my data is available (I invested in a UPS and will be more dilligent with backups). I haven’t heard anything in response and figured I’d make my own plan and have taken the below steps:
1: installed a fresh nextcloudplus image and updated
2: recovered from an old backup (this was from a time before several users had logged in, so their user folders were not created yet)
3: rsynced the user documents over to the new instance
4: scanned for changes from sources outside of nextcloud

Things seem to be working with the exception that I get a warning:

Technical information
The following list covers which files have failed the integrity check. Please read
the previous linked documentation to learn more about the errors and how to fix

- core
		- .user.ini

Raw output
    [core] => Array
            [INVALID_HASH] => Array
                    [.user.ini] => Array
                            [expected] => 467d4f028c447895716a2b7859ed6e569f8ee34b87b51d73dab2e6a9ca4fbe63172c7be3e365ae864a60408286afcce852dd38ee544b61685ed4ee5e021fecb0
                            [current] => 42eca5f14f21e928e8fa2ce3db4ca2ae1c6b055fbc02e52775e785822292c833bdc2ab832110fcc542ffe41a480c294dafc3dac4d20538f0f50c9aa7c662f00f




I’m not sure what it’s hashing, but it’s a little unsurprising to me with my recovery method that something isn’t matching there. Any way to clear this out? I’d appreciate any help.


I’m not sure how to find all the detials requested, but I can post the output of the nextcloudplus “nc-info” command (see below) and also say that I’ve installed on raspbian stretch from 4-18-2018

Launching nc-info
Gathering information...
NextCloudPi version  v0.58.1
NextCloudPi image    NextCloudPi_06-20-18
distribution         Debian GNU/Linux 9 \n \l
USB devices          sda sdb 
datadir              /data/app/data
data in SD           no
data filesystem      ext2/ext3
data disk usage      30G/64G
rootfs usage         959M/11G
swapfile             /var/swap
dbdir                /data/database
Nextcloud check      ok
Nextcloud version
HTTPD service        up
PHP service          up
MariaDB service      up
Redis service        up
Postfix service      up
internet check       ok
port check 80        closed
port check 443       closed
interface            eth0
certificates         none
NAT loopback         no
uptime               20:48

Alright, after doing a search for the .user.ini file to try to examine it a little I realized that it’s just in the /data/app folder, and that I ran a rsync of everything in the old version of that folder to the new one with some exclusions and inclusions as part of my process to restore the new data. Because I don’t linux much I kind of did this wrong and didn’t exclude any hidden files. If anyone ever reads this who is like me keep in mind that all linux files that start with a period (such as .users.ini) are hidden. So my guess is that even if that file has the same contents as the one that was hashed - the time stamp or some other metadata on it has changed because I copied the data from another instance of nextcloud, and that would throw the hash off.

So, the moral of the story is to rsync better! I could have just fixed this file, but for posterity’s sake (and because I’m likely to have time to kill today) I decided to start from scratch by going back to my restore file and repeating my above steps with a better rsync command that actually only moves the users’ data. Here’s what I think that would look like

rsync -avh --include={user1,user2,user3,ncp,__groupfolders} --exclude=* /media/USB/old/data/app/data /media/USB/ncdata/data/app/

however that didn’t work. In the end, given that I have so few users. I just ran an rsync command for each individual user and everything seemed to work A-OK.