Thank you for your post.
I don't have access to a mapped share on Windows 2003, so I was unable to try and reproduce this. However, I did try it on Vista and XP, and this worked properly.
I have forwarded your post to our Development and Software Quality Assistance (Testing) departments to see if they can replicate the problem. When I receive a reply from either group, I will let you know.
I am having the same issue as described above, we have a computer running windows server 2003 that generates several thousand PDF and Excel reports nightly for our users. I updated this system to use Filemaker 11 and at that point our users could no longer open any of the PDF files as the file permissions do not match those inherited permissions from the share. This will prevent us from moving to filemaker 11 in any capacity as we have tons of processes that save PDF files to various shares that folks need to be able to access based on the share permissions.
The problem is exactly as described above " PDFfiles created via FM 11 do not match the default permission set of the folder where they are being saved. The "owner"of the file is the current user that created the PDF - that part is well and good, but default permissions for Domain User and Domain Admin access specified in the security tab of the share aren't being set to the file. They are just plain missing."
We looked over this very thoroughly and have not been able to figure out a way around the issue. Our current issue was to remove filemaker 11 from this system and any users that updated during our testing phase and move back to filemaker 10.
Thanks - Joshua
Thank you for your post.
I have attached your post to the issue. When information becomes available, I will post here.
We experience the same problem on windows2008RC2.
When we try the same function with the excel export the permissions are correct.
The only workaround we use is a rename of that file and than do a copy to the original name and then delete the old file.
Thanks for your post.
Your post has been added to the original report.
All: Our Testers were able to replicate the problem and they are researching why this is occurring.
Has the "Save as PDF" permission bug been solved yet? I am seeing this issue on my network after upgrading to FM 11 Pro Advanced. My solution relies heavily on being able to create PDFs and save them to a repository for other users to access.
My system setup is as follows: FM 10 Server using internal FileMaker Authentication and External Authentication with Windows 2003 Server. 3 FM 10 Pro clients and now 2 FM 11 Pro Advanced clients.
Yesterday, before the upgrade to FM 11 Pro Advanced, the system and all FileMaker files were working properly.
Today, after installing FM 11 Pro Advanced, I can no longer open PDFs that have been saved to my document archive unless it is done from within the FileMaker 11 application. Standard windows file browsing will not allow access to these new files that have been created.
I immediately examined the Security permissions set on the existing network Folder and the New PDF being created by FileMaker. They are different. The new PDF file created by FileMaker shows the System account, Administrator account, and my User Account. The folder Security permissions have these 3 accounts plus several more, including the Domain Users account/group.
So my question is this:
Is it necessary to recreate the Privilege Sets of all the hosted files on the FM 10 Server using the FM 11 Pro Advanced client?
My only other option is to uninstall FM 11 Pro Advanced and wait for a stable fix from FileMaker. Any suggestions?
Thanks for you help.
I noticed that Filemaker released an updated download file version 220.127.116.11 up from 18.104.22.168 which we had installed. I thought perhaps this would fix the PDF permissions issue if I installed the slightly newer version but - NO!
We tried a number of things, but were unable to find an acceptable work around for the problem. The only thing we could do was go back to using filemaker 10. Recreating Priv Sets will get you nowhere.
I suppose you could wright a CACLS command and run it on a schedule to fix the permissions on the files that are not getting inherited permissions properly.
Our Testing department has verified the problem and it has been sent on to Development.
I am having an issue with this as well - I was curious if there is any news or work around on this issue?
Nothing new than what I have already reported.
The workaround suggested by "GregoryGearGuy" is definitely a possibility. However, if you are unfamiliar with icacls command, you could make things worse. I would also suggest backing up the ACLs of every file in a directory type before trying this in case something goes wrong.
Here are some suggestions. (GregoryGearGuy - can you verify?)
To backup the ACLs of every file in a directory:
icacls * /save aclfile.txt
To restore from the above file:
icacls * /restore aclfile.txt
The following is the command that should replace the ACL and apply to all objects below (subfolders included):
icacls * /grant ExampleDomain\Administrator:(CI)(OI) /T
For me the problem is that the files are not inheriting the permissions set on the folder above, so if I were to use a iCACLS statement, It could simply replace the ACL with the default inherited acls for all matching files.
Rather than actually detailing the specific permissions you want to set in the iCACLS statement you can use the following syntax
Syntax (Replace ACL with default inherited acls for all matching files)
ICACLS name /reset [/T] [/C] [/L] [/Q]
/T Traverse all subfolders to match files/directories.
/C Continue on file errors (access denied) Error messages are still displayed.
/L Perform the operation on a symbolic link itself, not its target.
/Q Quiet - supress success messages.
once you have written a command that corrects the permissions you can set it up as a scheduled task to run at a particular interval.
http://ss64.com/nt/icacls.html - is a good reference
OK, so this isn't the "solution" to tag it as such, but it is the ultimate workaround - thanks Gregory!
What I do is just follow everywhere that I'm using "save as PDF" script step with the "Send Event" script step. See below for the pseudocode:
Set Variable [$_myFileName; "filewin:/F:/foo/bar/myfile.pdf"] //Variable to pass to Save Records as PDF
Save Records as PDF [$_myFileName] //Do the Save
Set Variable [$_fileToFix; Right($_myFileName;Length($_myFileName)-9)] //removes preceding "filewin:/" text from saved path above
Set Variable [$_fixCommand; "cmd /c icacls \"" & $_fileToFix & "\" /reset" //gives me a string that reads: cmd /c icacls "F:/foo/bar/myfile.pdf" /reset
Send Event ["aevt";"odoc";$_fixCommand] //the call to the windows command prompt (Send Event -> Open Document) which fixes the file.
A nice bonus: The file can be open and the command will still fix the file. No need to worry if you automatically open the PDF upon saving or not.
Those who are having this problem can roll this into a single Send Event script step for ease of use, but I wanted to show exactly how to get filemaker path syntax converted to what the command line wants to see.
After FMI fixes the problem just delete the extra script step.
Enjoy! I know I am. :)
GregoryGearGuy and Peabody:
Kudos to both of you!
This should help a number of users until this is changed.
I tried this method but with no luck.