Somehow the relationship between the contain folders and the database was broken in the upgrade. Usually this happens when people us the OS to move the files around instead of FileMaker's Admin console. Since this is a Mac, one of the common mistakes is just dragging the RC folders back into the folder where the live databases goes. Looks great, but you invariable are copying files with your users POSIX permission and not the permissions that fmserver needs. I would first look at your permissions first in the RC file and make sure the user "fmserver" has read/write access. If not, you won't see any of your remote container fields. There are other things that could be wrong, but that is a very common problem with people running upgrades and thinking they will outsmart the system by manually moving files around. Actually, if you just do the upgrades in FMS, you don't have to remove or move files back into the live database folder. However, if you uninstall and reinstall and if you use a remote location for files, then that user is deleted and the permissions on the remote storage is messed up. Recreating a user named "fmserver" really creates a new user's permissions and is not the same user. So even though the remote storage had permissions for "fmserver", it will be for the deleted one and not the new fmserver. So you'll need to update permissions in remote storage if you have it and you did an uninstall. There are even other things like changing the folder levels from the file that will mess things up, but this will give you a start at trouble shooting.
I have had some strange occurrances as well with container fields in the same configurations. I was working with PDFs stored in the containers. The problem was with the same client on two different mac servers. In all other installs this has worked like a charm.
There was an article in Knowledgebase relating to resetting privileges which was something FMI help also suggested. That helped me in one instance.
Have to tried restarting server? This worked in one instance for me.
Have you tried reimporting the images to see if that helps?
If you take a copy of the database and related images folder and try to run it locally, does that work.
Can you add a new image in the hosted version or the local version?
FMI had suggested my solutions files were corrupted. However going back to golden copy didn't resolve the problem so that was ruled out.
FMI had also cautioned about the complexity of the folder structure, but again this didn't seem to be the issue.
If I remember right I think in desparation I closed everything and uninstalled FileMaker server and reinstalled.
Suddenly everything worked as expected and as it had been for over a month. Magic phrases during the process are not printable.
I had this issue a few weeks back on a solution I was trying to migrate. Goofed up on the relocation of the folders. What I ended up doing was writing a script to reinsert the assets into the containers, based on parsing out the GetAsText ( ) results of the container field. You should be able to extract the path to the asset by doing that. I don't know how many containers you have, but it might be worth trying.
I did a reinsert using a similar method. This didn't help on this server.
Moved everything to another box and everything worked. For a while. I don't have control of the machines in question.
I know the IT guys there did a permission change, See KB Article 7439 - Setting OS Level permission via terminal on Mac OS X. And I did a reinstall of Server (It needed recent batches).
All has been good since then but I am not sure exactly what righted the ship.
Hope this helps
Something was done to your server (changing permissions or getting into the container data storage area via the OS) which caused FM to view the container data as tampered with.
If one is planning to change a server setup, I believe these steps are in order first:
- Have the server perform a full backup
- Stop the FM Server
- Copy the backup folder, without opening it or touching anything inside
- Do whatever needs doing to the server machine
- Restart the Server
- If anything is wrong with the container data, restore from the backup. Manually copying or moving directories which include container data is often seen by the files as just another form of tampering.
Yep, I did check all that stuff, EXCEPT for re-importing the files into the container fields. It will let me add new files, so I think that may be the ticket. I'll go onsite and give it a try.
Now I just have to write a script that will re-import those 30,000 images, and let it run.
Thanks to you, Stephen, and Taylor for your responses.
Re-importing the images saved the day. Thanks!
Glad to hear it. in one of the deployments I had this did save the day ... for a while, the problem came back. Here's hoping your karma is better than mine.