After the most recent updates...

[Topdecker]

RESOLVED

I am getting hammered with the following error message:

Runtime Error: Unable to save file (C:/ProgramData/Fantasy Grounds/GlobalRegistry.lua) - Error (13): Permission denied

Database Notice: Campaign saved.

Comes up every few minutes and I have rechecked for updates 3 or 4 times since in the hope that I had missed a file.

Any suggestions?

Thanks!

Tim

[Zacchaeus]

Looks like FG is trying to save a file into a folder for which you do not have permission to save to.

What OS are you using?
Have you tried running FG as administrator?

[Topdecker]

Looks like FG is trying to save a file into a folder for which you do not have permission to save to.

What OS are you using?
Have you tried running FG as administrator?

The file itself had write and modify disabled. The entire contents of the file was "{}" with a cr/lf between the braces.

Thanks for the kick in the head :)

[Craw]

Ran into the same problem and running as admin corrected it.

[damned]

i recommend that you fix teh permissions instead...

https://www.fg-con.com/wp-content/uploads/2016/01/permissions.gif

give Users the write and modify permissions on the Fantasy Grounds folder...

[Topdecker]

Yeah, I later discovered that after fixing the issue with GlobalRegistry.lua that another file started having the same problems. So I changed the permissions on the folder since that trickles down to all the files and subfolders.

So damned's recommendation is the best bet for fixing the problem completely without putting the rest of your system at risk.

[Ellspeth]

Thanks damned for the beautifully clear directions, I tried this though I had thought the error messages I was getting was a result of removing the enhanced desktop till I learn to manage the layers better, but not so, this fixed it.

[Mask_of_winter]

Thanks damned for the beautifully clear directions, I tried this though I had thought the error messages I was getting was a result of removing the enhanced desktop till I learn to manage the layers better, but not so, this fixed it.
Enhanced desktop extension for Savage Worlds?

[Minty23185Fresh]

I would argue that the problem introduced in the new version (3.1.16) is not RESOLVED but that there is a WORKAROUND (as provided by damned).

My personal history: Last week I was editing Shackles of Blood, adding DM notes for myself. I upgraded to v3.1.16. and when I tried to continue with my edits, this week, I started receiving the permission denied messages addressed in this thread.

I worked in game development for 10 years, and I fail to understand why a Smiteworks developer would purposely change the permissions on the Fantasy Grounds data directories, a possible artifact left in the code. It's possible but I'm unsure as to why. I theorize, that instead, the offending code is running as an "underprivileged" user, somebody like "user" or "guest" instead of as the logged in user. As a developer one might do this for test purposes, I guess. To support my theory, the astute Fantasy Grounds user would have noticed the Console window (used for debugging during code development, another artifact?) pop up on Load Campaign, announcing "Runtime Notice: Host session started". Is "Host" an "underprivileged" user?

Unfortunately, many of us will have to go with the WORKAROUND until Smiteworks really does RESOLVE the issue.

[Trenloe]

To support my theory, the astute Fantasy Grounds user would have noticed the Console window (used for debugging during code development, another artifact?) pop up on Load Campaign, announcing "Runtime Notice: Host session started". Is "Host" an "underprivileged" user?
This is not an error, and "host" is not a user: host = server. The GM is "host"ing a game for players to connect to. "Host" is standard terminology in a client/server architecture. *And* this informational window will only appear if it was purposefully opened. So, this doesn't "support [your] theory" at all.


I fail to understand why a Smiteworks developer would purposely change the permissions on the Fantasy Grounds data directories, a possible artifact left in the code.
I honestly don't know where you're jumping to conclusions that this is an issue with some FG developer consciously changing permissions on the FG system. Windows and security/anti-virus applications are locking down the privileges of applications downloaded from the Internet, and this appears to be the case with recent updates. As part of the FG update, a new executable (Fantasygrounds.exe) is downloaded from the FG servers over the Internet. On some Windows systems, this can result in the application being marked as untrusted (or similar) and it's rights reduced, and file structures created by the update process and subsequently created/modified campaigns have their rights reduced and the campaign data saving issues reported here and elsewhere can occur.

This is not a conscious coding decision by FG developers, this is a knock on effect of security applications trying to lock down access rights for unknown applications downloaded from the Internet.

So, what is the actual resolution to this issue? I agree that Smiteworks should take a lead in this and try to work out how to get the FG application approved/passed by the various security application out there. This is obviously not an easy process and will take some time to resolve. In the meantime the fix is to change the file system rights as outlined above.

[damned]

Hi Trenloe in 3.1.6 one of the changes was to introduce a warning when files couldnt be saved.
If you have a permissions issue on the Campaign (either directly or inherited) you will get that notice on Launch now


Runtime Notice: Host session started

When you try to save you will likely see something like this:


Runtime Error: Unable to save file (C:/ProgramData/Fantasy Grounds/campaigns/AAAA/CampaignRegistry.lua) - Error (13): Permission denied
Runtime Error: Unable to save file (C:/ProgramData/Fantasy Grounds/campaigns/AAAA/db.xml) - Error (13): Permission denied

I agree its unlikely that FG is changing the permissions but I do wonder if C:\ProgramData\ is the best place to store Fantasy Grounds data. This is an All Users location and has higher security (especially on newer versions of windows) than the %appdata% location does.

[Trenloe]

Hi Trenloe in 3.1.6 one of the changes was to introduce a warning when files couldnt be saved.
If you have a permissions issue on the Campaign (either directly or inherited) you will get that notice on Launch now


Runtime Notice: Host session started
Yes, but this is not an indication of an error. On a fully working system the same message will be shown if the console window has been opened. Even if the console window is not open, look in the <FG app data >\console.log file and you will see this message. This message has been displayed in the console window/console.log file for as long as I can remember. It is informational only and is not an indication of an issue at all.

[dulux-oz]

I don't have any FG-related stuff in C:\ProgramData\ - but this could be because I told FG to store its data in C:\Fantasy_Grounds_Data - and I haven't had any permissions issues (before or after the update)

Just my $0.02 worth :)

[damned]

Yes, but this is not an indication of an error. On a fully working system the same message will be shown if the console window has been opened.

I get all that - my point is that the Console Window WILL open of its own accord with just that message in it if you dont have sufficient permissions to your campaign data folder. You do not need to /console to see this message. It is already the first indication that something is wrong.
Then going back to Topdecker and Minty23185Freshs posts the warnings start occurring when the periodic save attempts to write the changes to the db.xml or when you import images etc.


I don't have any FG-related stuff in C:\ProgramData\ - but this could be because I told FG to store its data in C:\Fantasy_Grounds_Data - and I haven't had any permissions issues (before or after the update)

Which is all good except that we do encourage people to keep the program defaults because it reduces the amount of variables in troubleshooting issues :)

[dulux-oz]

Which is all good except that we do encourage people to keep the program defaults because it reduces the amount of variables in troubleshooting issues :)

I get that - but there is also something to be said about NOT relying on "defaults" and instead explicitly setting an environment variable so as to have better control over the environment. The fact that FG allows us to set such a variable shows (IMNSHO) some forethought on behalf of the Devs, and also reinforces you "musings" from your previous post. The question then arises do people stick to the "defaults" and the perceived "ease of troubleshooting" but with the potential for this type of issue, or do we instead take control of the environment even though it may introduce another question to ask in the troubleshooting process in return for avoiding the issue under discussion?

It's six-of-one and half-a-dozen of the other and you take your chances :)

Either way, somebody's not going to be happy with the decision - but its an interesting philosophical design discussion anyway :)

Cheers

[Minty23185Fresh]

I guess two apologies are in order. First I erred in typing the affected version as 3.1.16, when it is 3.1.6. Second, I meant no offense, by my accusations, and there was nothing implied that this would be something a developer meant to do. During code development many things can be attempted and then abandoned in trying to remedy bugs or enhance product. Once in a while there’s an artifact. The developer or the person doing code review typically catch these minor oversights. But once in a while, every once in a while, something slips through to production. Otherwise code would always be bug free. Wouldn’t that be nice! To believe otherwise is simply arrogance.

Now this “feature” came about with the release of 3.1.6. Prior to its release, the console window did not pop up. After its release it’s ubiquitous. Damned was kind enough to explain the circumstances: no write permission. Now unless the intent is to have users receive a Console window pop up and have us manually change permissions on their Data\Fantasy Grounds directory tree it seems as though there is a problem (to me).

Let me add another experience to the heap. Either yesterday or the day before I installed Fantasy Grounds (v3.1.6) on a second PC, just on the off chance that I was experiencing some odd behavior (viral, maybe?) on my primary gaming PC. I did some edits in the Shackles of Blood campaign. I received no console window, nor write permission problems. Odd to say the lease. And that certainly points to a problem with the original PC. Then, just this moment I sat down to add additional edits on the newer “more “virginal” PC. Bang! Console window, no write permissions. I’m not implying that there is some bizarre time delay issue going on here, but maybe it is a cumulative edits issue. I don’t know, I’m not privy to the code. But it is curious.
I’d kindly ask you, Delux-oz, to try the same scenario with your non-default data tree. Add some edits to a story line in a campaign (maybe a purchased campaign?). Wait a couple days and try to add some more edits.

[Minty23185Fresh]

In the hopes of helping with this issue I will work towards providing a repeatable sequence of steps that will invoke the console with permission denied messages. Without any modifications of user privileges. And from a clean PC, or as close as I can get.

[damned]

The popup window was added because there have been a few reports of this. Certainly its not affecting the vast majority of users but it is affecting some users. If you can identify a common cause that would be awesome!

[damned]

Hey Minty23185Fresh - a more full solution is being worked on by Moon Wizard however if you are able to narrow down a triggering factor that would be of great help!

[damned]

Hiya all - if any of you are running Win7/8 or a Wineskinned version and have some time to do some testing.... Moon Wizard has identified the likely cause and a probable fix but it needs more testing on these versions.
https://www.fantasygrounds.com/forums/showthread.php?28451-Request-for-helping-test-updater-installer-changes

[Minty23185Fresh]

I wish I could be of more assistance, but after reinstalling Fantasy Grounds I have been unable to consistently repeat the behavior. Here is what I have discovered though. I hope this is of some help.

I have several campaigns that I have been editing (adding new pages and adding text to some existing pages). An example campaign of mine is called “Shackles”. I examined Security Properties of the C:\ProgramData\Fantasy Grounds\campaigns\Shackles folder. There are five Group and/or User names with defined permissions: (1) Creator owner, (2) System, (3) Thomas, (4) Administrators and (5) Users. “Thomas” is my login account name, with administrator privileges. If the Thomas name is defined then I have no problems editing and saving the story line. If the Thomas name is missing from the list then I will have problems. The console window will pop up and I will receive error messages in the console stating permission denied. By the way, if one Creates a New Campaign in the Fantasy Grounds Launcher, and then examines the new campaign folder’s Security Properties all five Group and/or User Names are present. I have no idea how the one user name gets dropped.

Secondly. I was editing a campaign story, will say “Campaign1”, and it was exhibiting the inability to save (due to permission denied). I closed Fantasy Grounds down, relaunched it and created a new campaign, say “Campaign2”. I was then able to edit both campaigns without failures. After a few edit sessions, Campaign1 started to exhibit the defective behavior again. I was only able to observe this behavior once, and I have tried numerous times to repeat it. Also, I did not look at the number of Group and/or User Names in the Security Properties during this time. I was not aware of the odd missing User name behavior until much after this “new campaign” behavior.

Please recall I have been working with two PCs, both were exhibiting the undesirable permission denied behavior. Using Menu | Run… I uninstalled Fantasy Grounds on one of the PCs using “C:\Program Files (x86)\Fantasy Grounds\FantasyGroundsUpdater.exe” –u Then I deleted the app folder: C:\Program Files (x86)\Fantasy Grounds and the data folder: C:\ProgramData\Fantasy Grounds This to get a relatively clean install of v3.1.6. After reinstalling Fantasy Grounds (v3.1.6) to my “clean” PC I have not been able to repeat the permission denied behavior. I went to the second PC, ensured that it was exhibiting the undesired permission denied behavior, and it was. I then repeated the uninstall and reinstall to a clean PC scenario. On the second PC I have been unable to repeat the undesirable behavior. So as near as I can tell the undesired behavior is never present on a new install (of v3.1.6).

I really apologize for not being able to provide you with more concise data to effective troubleshoot this issue. I will keep attempting to reproduce the issue and provide you with more information. Hopefully I haven’t just muddied the waters. Thank you for your time and efforts, I really do appreciate and enjoy Fantasy Grounds.

[Minty23185Fresh]

Oops. I just saw the "help wanted" post. I'd be more than happy to assist, if you like.
Two Windows 7 PCs.
(One concern: I was never able to repeat the behavior with clean or new installs - so that's a bit disconcerting. But I'll give it a go.)

[damned]

I think I know how to reproduce now...

Close FG. Delete 4E.pak, run FG and then run the Updater. This will Invoke the installers permissions.
Create a new campaign and create a story entry.
Close FG.
Run FG and try and save some changes into the new campaign.

If that is right the reason it hasnt been seen a LOT is that it would only affect campaigns that were created on the same session as you ran the updater and even then some people with elevated User permissions wouldnt be affected either.

[Minty23185Fresh]

This is consistent with my "non" observations. In both cases I rebooted after install (old habit from early PC days). That would kill the session.

[Zzclown]

have done these steps and changed permissions However i am still receiving the Error

Runtime Error: Unable to save file (C:/ProgramData/Fantasy Grounds/GlobalRegistry.lua) - Error (13): Permission denied
Database Notice: Campaign saved.

any other things to try

I am using windows 10

[gqwebb]

have done these steps and changed permissions However i am still receiving the Error

Runtime Error: Unable to save file (C:/ProgramData/Fantasy Grounds/GlobalRegistry.lua) - Error (13): Permission denied
Database Notice: Campaign saved.

any other things to try

I am using windows 10

To take ownership of a file or folder
Open Windows Explorer, and then locate the file or folder you want to take ownership of.
Right-click the file or folder, click Properties, and then click the Security tab.
Click Advanced, and then click the Owner tab.
Click Edit, and then do one of the following:

I would also recommend printing the file causing the problem and jumping on it.

https://www.demotivationalposters.net/image/demotivational-poster/0902/computer-magic-computer-demotivational-poster-1234984568.jpg

[Oberoten]

have done these steps and changed permissions However i am still receiving the Error

Runtime Error: Unable to save file (C:/ProgramData/Fantasy Grounds/GlobalRegistry.lua) - Error (13): Permission denied
Database Notice: Campaign saved.

any other things to try

I am using windows 10

Saw the same problem for one of my players who is/was running the Demo version. We just shifted the data directory to one directly under the root. "c:/fg" to be specific. Problem solved, and then we just copied all the files from the old data directory there.

[Trenloe]

Runtime Error: Unable to save file (C:/ProgramData/Fantasy Grounds/GlobalRegistry.lua) - Error (13): Permission denied
See the solution in post #3 here: https://www.fantasygrounds.com/forums/showthread.php?34152-GlobalRegistry-lua-Error-(13)-Permission-denied