Permissions? Have you compared them with stuff that does get deleted?
The same here.
Permissions of alle the images are the same.
The folder that can't be deleted contains some images from container fields, not all.
I am also experiencing the exact same issue.
Yes, this is a real problem. Obviously not on all installs, since I have several others that are just fine. This one is not. I am guessing that maybe it is a sequence of how the machione was configured. First 12v1, then a certain update, etc, and an OS update, then a V3 update?
A certain sequence of steps.
I am wondering if FMI has CLEAN INSTALL of FMS12v3 ???
I am waiting for the complete install package of FMS 12.0.3 as well. It wasn't offered in a series of communications last week, but I am hoping it will be available soon. I've sent the request to our FMI inside sales contact.
My server is sending me distress emails...every 15 minutes...becuase thats how often it backs up. VERY annoying. I guess I can turn off the Alarms...but then if it tanks for real...then no one will know.
I am going to have to blow out that box and rebuild the server. A clean FMS 12v3 would be nice. My gut tells me there will not be a v4.
I'm so sick of the ·!·""·$ 685 error. Please FMI, can you at least provide us a shell script to delete the folders or something like that? A pre-cleaning script would be helpful.
I've created this solution for MacOS:
run this script on the terminal prior doing the backups. it will delete all folders that are older than 3 days from today.
find /Library/FileMaker\ Server/Data/Backups/ -ctime +3 -print0 | xargs -0 rm -r
I also have this "Error 685" issue.
Did a clean install work? .... I tried it and it did not work for me.
Is it safe to do this? Is it safe to manually delete all those backup files and just restart the process? Is there some way to just make the errors stop? Has anyone got a good backup strategy that just avoids the whole issue? Other than going to Supercontainer?
Ok...we suspect this issue is probably tied to improper setup of remote containers. Essentially, remotes containers should be stored in a path that is unique to a folder for the record...typically a record ID, etc. We had a database on that server...that had this Error 685 issue...where the Remote containers...were mostly piling up in a single shared folder...for all the records. Bad Dog!
I can see this happening accidentially to a lot of inexperienced users. With Super Container, that product just won't work if you wire it wrong. Remote container will work...and work well...at least for a long while...if it is wired wrong.
So anyway...after wiring up the Remote Containers to live in their own folders...properly...the backups are deleting properly now. Yay. So thats my theory. And the Earth is flat too. :-)
I am somewhat new to open external storage (not to Filemaker) but I read several sources stating that it is not necessary to worry about where filemaker puts things. I specifically read that it was better to just let filemaker do it's job. I did NOT encode any serial numbers into my filepaths. How long do I have before I start to lose data? So now that I am months into backups, how can I pull all those containers' data and move them into locations that reflect said serial numbers? Will I just loop thru all the records? That will take a long time.... Or is it possible to just change the storage location? should I log all users off first?
[hostedlocation]/Filename/ContainerName/ & _Serial & "/"
will then become the new path? Am I correct to place the ending "/" after _Serial ???
The ending "/" seems to be needed. Filemaker appears to handle everything on all but one case (table). I don't know why. That table shows document files OUTSIDE the _Serial folders when I look at the backups. This one table seems to be the only one where Filemaker cannot remove the RC directories now... It's very strange.
I seem to have overlooked a container field, once I did the above steps to that forgotten field, EVERYTHING now works just fine.
I wonder if I will have to remove the file from the server and save a compressed copy?
Richard C's answer worked perfectly once I fully implemented it...
Thanks, Richard, your solution works for me! Everything else I tried from this and other threads on error 685 (there are several) did not.
I changed the external storage as Charles suggested above ([hostedlocation]/Filename/ContainerName/ & _Serial & "/") and my several thousand images were transfered by FMP to several thousand folders, each containing its own image. I had to manually delete the backups done the original way first and then it started working.
I was, however, surprised to hear you say that setting up external storage using a unique folder for every record was the "proper" way to do this. Did I miss this piece of info in external storage documentation/recommendations? I've set up external storage on many fields in many databases using the default hosting location and this is the only FMS box that gave me error 685.
Ann Arbor, MI