1. I created File1.fmp12 with two fields: ID (Number) and Name (Text).

2. I created File2.fmp12 with two fields: ID (Number) and City (Text).

3. In File1.fmp12, I created a relationship into File2.fmp12 based on ID = ID.

4. In File1.fmp12, I went into Manage -> Security, clicked on the Admin [Full Access] account, clicked the File Access tab, checked the option "Require full access privileges to use references to this file", and added File2.fmp12. I click OK, and the dialog box says "One or more of the accounts that have Full Access privileges do not have passwords. This is a security risk. Do you want to allow this?". I click Allow and enter Admin/no password.

5. In File2.fmp12, I went into Manage ->Security, clicked on the Admin [Full Access] account, clicked the File Access tab, and after checking the option "Require full access privileges to use references to this file", I get another dialog box saying "The file "File1.fmp12" has references to this protected file. Those references will need to be authorized. Do you want to authorize now?" I click "Yes", and "File1" now appears in the list of Files. I click OK, and the dialog box says "One or more of the accounts that have Full Access privileges do not have passwords. This is a security risk. Do you want to allow this?". I click Allow and enter Admin/no password.

6. I then close both files, and then open File1.fmp12 again, and File2.fmp12 opens as hidden.

Let me know what I'm doing differently than you so I can replicate the issue.

Hi davidhamannmedia. I also have recurring cases where the authorization of files references seems not to take. Since, as you point out, there is an easy enough workaround, I haven't taken the time to properly identify the circumstances in which it occurs to be sure where there's an actual issue, or just a misunderstanding on my part of how this works. I'm guessing you haven't either...

Do you know if your files were created in FM15 or some earlier version? Are some files duplicates of others? Do you see differences running locally vs hosted, and from the client vs in server-side scripting?

Do you know if your files were created in FM15 or some earlier version? Are some files duplicates of others? Do you see differences running locally vs hosted, and from the client vs in server-side scripting?

The files were created with FM13. It seems to only affect one file of the multi-file solution though. As far as I can tell it also only affects the reference from one file to another (for all other references to the same file the authorization works fine). It is this file which previously reported: "FileA.fmp12" is already authorized to open the protected file "FileB.fmp12" (without showing up in the list).

The workaround I posted yesterday evening did (strangely) only work for a few hours. This morning the problem appeared again when another user (also Full Access) logged in. There was no dialog like "do you want to authorize", it just showed references as missing.

And do you know if "FileA.fmp12" is a copy of a file that had been authorized? When I seen this, I know that at least in one case or two, I had multiple secondary files that were originally created by duplicating an existing file. E.g., I'd duplicate a "data" file to create a separate "Binary data" file.

Good question! Duplication could indeed be an issue for some of the cases (probably not mine though).

In the help is mentioned:

[...] if you duplicate or clone a protected file, each file will also have the same ID. If you use both files in the same multifile solution, you must reset the ID in one of the files so that each file has a unique ID. To reset the protected file’s unique ID, click Reset All, then click Yes. After resetting, you will need to reauthorize all files that are authorized to access the protected file and any protected files that file was authorized to access.

However, I can say for sure that none of the files were duplicated/cloned while having the protection turned on and am being told by the creator of the files that all of them were created from scratch.

Will investigate more tomorrow. If you find any clues in the meantime, keep me updated :-)

I continue having these issues (with duplicated files and with non-duplicated files). Today with a totally different system (this time converted files, last time new fmp12 ones).

Authorization prompts are popping up whenever I open the file with Full Access again. The file being accessed does not (really) store the authorization. When trying to do a manual authorization I'm getting the "is already authorized" message again although the file is not shown in the list of authorized files. Doing a complete reset and then manually authorizing the files again does not solve the issue (even when executed offline/locally).

davidhamannmedia - just for clarity, do you get the prompt to authorize only when files are hosted, or also when you open the files locally?

I've never seen the "is already authorized" for files not listed as you describe it. It would be interesting to see what the AuthFileCatalog in the DDR contains when this happens (and in general, when these authorization errors happen).

The AuthFileCatalog contains the entries that are also visible in the File Access tab UI. It does not contain other entries that must be there (the ones for which the message "already authorized" appears are neither in the UI nor in the DDR).

When you add entries the list in the UI and the DDR changes but then omits others. If I wouldn't know better I would think the file is corrupted. But it's unlikely that we are all working with corrupted files each with a different history :-) (who knows...?)

I also ran a recovery and inspected the recover.log – nothing special pops out.

I'm not able to reproduce the issue with new files (following your steps).

I experienced the issue with all hosted files (FileA needs access to FileB and both are on the same server, references via "file:") and with a local file trying to access a hosted file. I also tried to reset all authorizations and then authorize all files with everything being local / server shut down. When I hosted the files again, the problem occurred again – sometimes only after a while (sorry that I cannot make a more precise statement here as I'm not sure what causes it to "forget" the authorizations and when that event would happen).

Re: Multiple Windows: Only one window is open and the other file is accessed via a Perform Script step. So no multiple windows / multiple windows with same table representations.

I do not know if the issue would still occur if one would continue to work locally with all of the files since I've never had that use case.

Ok, I've set it up with my files again. Here are the steps I've executed (everything locally, offline):

1.) Open the file to be accessed (let's call it File A). This is the only file that is open (FileMaker was started by double-clicking this file)

2.) Open Security -> File Access -> Reset All

3.) Turn authorization completely off (Checkbox "Require full access privileges to use references to this file" to unchecked)

4.) Click OK to close the Security setup, enter credentials to save

5.) Open Security -> File Access -> Turn authorization on

6.) Authorize two files by clicking "Authorize..." (let's call them File B and File C; each file is authorized individually, so the "Authorize…" is clicked two times.)

7.) Click OK to close the Security setup, enter credentials to save

8.) Close the file

9.) Open the file again

10.) Open Security -> File Access

After step 10, only File B is visible in the list of authorized files. File C is missing. Trying to authorize File C again brings up the dialog mentioned by Chris above ("[…] is already authorized […]").

The DDR I created afterwards again only shows the files visible in the UI (so only File B, but not File C).

And here comes the strange part: I've opened File A on the server again and, at least for the moment, File B AND File C can access File A without problems. File C is still not visible in the list of authorized files in File A but nevertheless can access it.

The end result, at the moment, is the desired one, however with incomplete data in the UI. Let's see if the behavior sticks or changes again.

davidhamannmedia - do any of the files have an account entered in File Options > Open > Log in using? Is "Allow keychain" checked or unchecked? Do all files have full access accounts with identical username/password?

Also, did you check the DDR for each file? File A's DDR should normally have OutboundAuthorization for Files B and C, whereas Files B and C should have InboundAuthorization for File A. Just to double-check; my guess is that this isn't getting saved at all, but one could perhaps also imagine that some kind of mismatch between the OutboundAuthorization and InboundAuthorization could cause problems.

- Inbound/Outbound looks OK when you set it. After it stops working the entries are also missing in the DDR.

Unfortunately, the error is not so easy to reproduce because there is a delay until it stops working and you are confronted with the error again.

The question to FMI: what could cause an entry to disappear in the UI/DDR while still being checked when trying to add a new authorization? This was the original question in this thread and I would guess it has to do with the issue of the new prompt for authorization.

I've needed to wrestle with this issue a few times and I feel your pain. In a few situations, we had to sweep through all the files, both referencing and referenced, to reset their IDs. I'm starting to lean now towards this not being a bug, but really a lack of actionable information to directly understand and resolve the problem when it comes up.

I am experiencing the same issue - occurred in FM15 - never had this in any older versions of FM with the same files in place. It is definitively a bug. Because without any changes in the file references and authentication it might suddenly happen and re-referencing/authorizing might give peace for a little while - it might then reappear.

It also appears in my specific case that after re-authorizing or recovering Full Access can suddenly see the hosted files but limited users still not - after restarting and reinstalling - re uploading file - the more you do then finally the limited access user might be able to see the hosted file as well.

then days later same game again ..

unfortunately we invested already months of work developing in 15 so going back to more stable 13 is not an easy option. in FM13 we never had problems like this!

How did you resolve this? I am still struggling with this - in 15v3 no improvements. The re-authrization just won't stick.

If I try to authorize a file not listed in the File Access Panel instead of pointing up from the local file to the server it tells me that file is already authorized but that is not the case otherwise it wouldn't ask.

Just curious if the others having this issue have solutions that are split across multiple fms servers. I was told mine were likely not sticking because I was authenticating files hosted across different fms servers. I have not revisited this since server 13.09 and file refs were using IP's so not sure if that being a possible cause has been established/resolved since?

also the file has been uploaded to at least 5 FMS instances with different IPs (on different locations).

one time I saw a windows opened where it told me the file has been authorized to the list of servers. somehow I cannot get to this window again. it closed by itself or by my subconscious mind after I clicked delete all references ..

Currently, I have a stable authorization state of the files I had issues with before.

I opened all files locally, clicked "Reset all" in all ( ! ) of the files (meaning all involved files, not just in one direction and not just the ones that had issues), then went one by one through the files and authorized them again. After that I closed all files and put the server one's back to the server. Until now, everything works fine.

This "nuke" procedure is just a headache if you have distributed client files where not all of them have that issue. You will essentially lock all the (currently working) old client files out until you give them the new authorized file. But then again: re-authorizing only the files that didn't "stick" was just not working.

As far as I could see, the "Reset" resets the outgoing authorizations as well. Just make sure to hit the reset on all relevant/related files before authorizing again. Otherwise you might end up with the initial problem of this thread ("…is already authorized to open…").

Actually somehow I had a window showing up of the 'outgoing' file where all server files have been listed.

On the right side was even a list how the connection to these 'incoming' server files were established in regards of certificates with warnings. On the right bottom side of this window was a delete button as far as I remember to clear all

these outgoing references.

I was flabbergasted to see that the file listed all servers ever associated with copies of that 'outgoing' file.

Unfort. I cannot re-evoke this window again to take a screenshot or/and to reset the outgoing references.

I was time for me as well to get into this issue. I have currently 20 databases with separate UI/logic and data (40 files). The UI file is in constant development and periodically replaced as the new UI file for all the databases. Basically copied and renamed. This has been working fine for months until today.

The supporting database I have problem connecting to, accept connections with no full access (no checkbox). The file is a screen scraper of the Palo Alto Applipedia which contains all of their Layer 7 appID's ports and protocols.

Reading the above posts about not only resetting the the file not being able to connect to, but also resetting the files connecting from, seems to be on the right track. For some reason these authorizations seems to multiply.

As the image shows, all of my UI files have several tokens(?) to the same file, which I now have to clean up and test.

I'm seeing this issue with a multi-file solution created in FM16 and hosted on FM Server 16 (Windows Server 2016). All files are encrypted-at-rest. On a test system, everything worked as expected. The trouble came when we went live.

Resetting and reauthorizing the files seems to work. When the first user connects, however, they're forced to do the "one-time" authorization. This changes the timestamps shown in the file authorization window. That user can subsequently reconnect without reauthorizing, until another user connects. Then, that user has to do the "one-time" authorization and the first user's authorization no longer applies.

The solution was to close the files on the server, open them locally and then re-host. Everything worked after that.