@BenHastings yeah, I ran the script. to be honest maintenance mode, at the time I was running the script wasnt overly important as no one would have been using the system at that time.
The database seems fine, it is just the front end at the minute that I cant seem to access.
After running the script, I got a list of entries shown on the screen, each entry had a list of around 5-6 headers.
I then went back into the DB to check and ran the query SELECT COUNT(*) FROM oc_filecache WHERE mtime < 86400;
But I am still getting the same result - 2801
**** Nextcloud is back up and running fine. there were incorrect file permissions that I caused when trying to make the config file writable from the server but I have reversed this
@BenHastings
At first I ran the script & './fix nextcloud file creation date.ps1' just to see what to expect and it returned the pic below
I then ran the script to count and it gave me a figure of 2800
and I then ran the script
& './fix nextcloud file creation date.ps1'
-dbserver ‘127.0.0.1’ -dbname 'owncloud'
-dataDirectory ‘/media/owncloud_storage/data/’ -action 'changeDate'
and got a long list of entries similar to the below pic
after running the above I tried the count again and got the same result - 2800
Because my server is Linux based (Ububtu) I tried changing -action changeDate to -action ModifyDate based on your script (change create date ('Modify' date in Linux) to the date retrieved from DB)
But again, no change
Is there something that I should do differently?
It is possible that the script does not have permission to touch the file. You can check for that by manually trying to touch a file using the output the script provides.
touch ... .pdf
and then again with sudo
sudo touch ... .pdf
If that’s the case, I didn’t really test for this. I ran everything as root. I suppose you could try to start powershell as root by starting it with “sudo powershell”
Either way, I’m glad to hear that you fixed the config file error. 
edit: if the fileName is empty, it means the script cannot find the file in the file system. You can check for those file by adding
| where-object {$_.fileName -eq $null}
1 Like
@BenHastings I will try sudo powershell first.
Should I use
-action changeDate or -action ModifyDate
?
I think I might have found the problem. I didnt have a traiiling / after the path-to-data-directory.
Running it again now to see if it works
@BenHastings
Nah… still no joy
Although, now Im quite confused.
The ommand seemed to run fine…
When I run the count command I now get 2 where as before I got 2800
but when check the DB and rn the query `` SELECT COUNT(*) FROM oc_filecache WHERE mtime < 86400; it returns 2801
Does your script not modify mtime?
did you run occ scan afterwards?
did the timestamp in the file system get fixed? check with
stat file.pdf
and look for the “Modify” date
No.
I tried it there but I am getting the config error.
Cannot write into "config" directory! This can usually be fixed by giving the web server write access to the config directory.
But, if you prefer to keep config.php file read only, set the option "config_is_read_only" to true in it.
See https://docs.nextcloud.com/server/25/go.php?to=admin-config
I tried sorting this error yesterday and that is what caused me to be locked out of Nextcloud. not sure how to fix this
@BenHastings
I have managed to get the DB query down to 310 by running a reindex in plesk.
Just need to figure out why the other 310 are not getting sorted.
Would it be worth running your script again?
It is unlikely that it will fix the remaining files by running it a second time, but it shouldn’t cause ny issues if you try to do that.
For the remaining files, see the troubleshooting section of the readme. If you are lucky, those files are in the user’s trash bin and you can delete them. Does the script still list those files, or can you only see them by running the DB query?
The script doesnt list them
I can only see them when running a DB query.
The trash bins are empty.
I have checked the files in the DB and they are live files. the mtime is sowing as 0
Sorted
I reindexed on plesk again and now it seems to have got the number to 0
Hopefully that is it sorted
I apologise for being a pest
Thank you so much for your help and patience, it is mich appreciated!
1 Like
Thanks for the feedback! I will add to the readme that the trailing / is needed in the path (or fix the script so that it isn’t needed.
Probably my lack of knowledge causing that issue.
But your help and patience has honestly been great, I really appreciate it
1 Like
