[1.5.0-RC-10] Access to tmp folder denied
-
No, it is a 64-bit Windows 7 machine.
-
In the past I have had this issue when using certain anti-virus programs, but we now have exemptions in place for FOG. I adjusted the permissions on this folder to be open to everyone, but that did not change anything (and then I set the permissions back)
@brian-david That sounds like guesswork and like you’re not sure where the problem is. The way to troubleshoot this is like any other problem, you eliminate variables. Just uninstall antivirus from the machine and reboot to entirely eliminate the the AV variable. See if it works afterwards.
-
@wayne-workman My apologies, I did not add enough context to my original post. I did in fact initially run these FOG snapins before installing any anti-virus on this particular workstation, so that definitely wasn’t the issue. I added the comment about the anti-virus to inidicate that I’ve run into this problem in the past in different circumstances. It is not relevant for this issue, though, so I shouldn’t have mentioned it.
I also updated my original post with OS and FOG client version info. Let me know if there is other information I can send your way.
-
@brian-david said in [1.5.0-RC-10] Access to tmp folder denied:
I did in fact initially run these FOG snapins before installing any anti-virus
Was those successful?
-
@wayne-workman No, the snapins were not successful; it resulted in the error that I originally posted. Once again, apologies about the confusing wording.
-
@brian-david Can you check to see if that file exists?
C:\Program Files (x86)\FOG\tmp
Also, can we get more of the fog.log file? -
@wayne-workman Yes, it does exist and contains a public SSL certificate from the looks of it. Just to make sure, I also uninstalled anti-virus to make sure it isn’t a problem while troubleshooting. The issue still remains. Here is the full Snapin entry in the FOG log, with a small amount of sanitizing:
------------------------------------------------------------------------------ ---------------------------------SnapinClient--------------------------------- ------------------------------------------------------------------------------ 11/22/2017 12:57 PM Client-Info Client Version: 0.11.12 11/22/2017 12:57 PM Client-Info Client OS: Windows 11/22/2017 12:57 PM Client-Info Server Version: 1.5.0-RC-10 11/22/2017 12:57 PM Middleware::Response Success 11/22/2017 12:57 PM SnapinClient Running snapin 11/22/2017 12:57 PM Middleware::Communication Download: http://[SERVER_ADDR]/fog/service/snapins.file.php?mac=[MAC_IDS]&taskid=588 11/22/2017 12:57 PM Middleware::Communication ERROR: Could not download file 11/22/2017 12:57 PM Middleware::Communication ERROR: Access to the path 'C:\Program Files (x86)\FOG\tmp' is denied. 11/22/2017 12:57 PM SnapinClient C:\Program Files (x86)\FOG\tmp 11/22/2017 12:57 PM Middleware::Communication URL: http://[SERVER_ADDR]/fog/service/snapins.checkin.php?taskid=588&exitcode=-1&mac=[MAC_IDS]&newService&json ------------------------------------------------------------------------------
-
@brian-david How large is the snapin file? Can you try to re-upload it to the fog server please? You should be able to ‘edit’ the existing snapin and browse to the file via the GUI and click save, which causes it to be re-uploaded. Also - after you re-upload, check the size of the snapin on the FOG server with this command:
ls -laht /opt/fog/snapins
-
@wayne-workman Okay, so here is some intriguing new information:
I was getting the access denied errors when using the ‘All snapins’ task. However, if I run the snapins individually, they work! I was able to install two snapins (I’ve included the size of the snapins):
- Thunderbird - 39M
- LibreOffice - 233M (this is the largest snapin we use)
So this issue seems to be specifically related to the ‘All snapins’ task.
-
@Joe-Schmitt Would you have an idea?
-
@Brian-David well this is certainly strange. This is the best theory I can think of:
- Is one of the snapins specifically to blame? You state that this only happens when you run “All Snapins”; from the client perspective this is no different then running them individually. Are you running all of the snapins individually, and this issue is not present then?
If this is not the case let me know, and I can walk you through using the client’s debugger, it should help narrow down the issue pretty quickly.