Mike Le Posted October 12, 2013 Report Share Posted October 12, 2013 I'm running a Windows 7 Ultimate virtual machine on a Macbook Retina. There's only one account setup on the virtual machine and it's the admin account. I tried setting the file permissions such that "Everyone" has "Full Control" on all files/folders. This took a while and the permissions couldn't be set on certain files. It also didn't resolve the problem, which was constant IO errors from LabVIEW complaining about lack of file permissions. I tried cranking the User Access Control / UAC setting down one level at a time and the problems finally went away when I shut it off completely. Is there any other way to fix this problem besides shutting it off totally? Thanks. Quote Link to comment
martin_g Posted October 12, 2013 Report Share Posted October 12, 2013 I had a similar permissions problem on a previous project (can't remember the exact details) but basically I was creating a count file, and LV would write to it every 10 seconds or so. I was plagued with permissions errors. The native 'Set Permissions' function sorted out my problem. LV help says use an octal value of '200' for write permissions, '700' for read, write & delete. 200 worked ok for me with Windows 7. Martin Quote Link to comment
Mike Le Posted October 12, 2013 Author Report Share Posted October 12, 2013 Thanks for the info, Martin. I did try playing with the Set Permissions function, but I ended up getting more permission errors. Trying to set the permissions of the file I wanted to open returned error 8. Quote Link to comment
hooovahh Posted October 14, 2013 Report Share Posted October 14, 2013 Where is this file located that you are trying to write to? I assume Program Files which Microsoft has said since Vista that area should be off limits for file writing. That being said most people still do it so it isn't such a big deal. My point is that you can choose to write files in a more secure (obscure) location that you will have write permissions on. Something like Application Data. If you do choose to leave the files in Program Files you can "Unlock" them during the install. This sets the permissions for you so any user can modify it. http://zone.ni.com/reference/en-XX/help/371361H-01/lvhowto/build_installer/ Step 6. 1 Quote Link to comment
Wire Warrior Posted October 14, 2013 Report Share Posted October 14, 2013 So that's what the "Unlock" option does. That's good to know. Thanks Quote Link to comment
hooovahh Posted October 14, 2013 Report Share Posted October 14, 2013 So that's what the "Unlock" option does. That's good to know. Thanks It unlocks the file duh...but seriously I think the reason they named it that, is because in Windows if you download an EXE Windows security will prompt you with normal UAC stuff when you go to run it. But if you go to the properties of the file there is an "Unlock" button which is you telling Windows you trust the EXE. Still I think a different term would have helped understand what it does. 2 Quote Link to comment
LogMAN Posted October 14, 2013 Report Share Posted October 14, 2013 I'm running a Windows 7 Ultimate virtual machine on a Macbook Retina. There's only one account setup on the virtual machine and it's the admin account. I tried setting the file permissions such that "Everyone" has "Full Control" on all files/folders. This took a while and the permissions couldn't be set on certain files. It also didn't resolve the problem, which was constant IO errors from LabVIEW complaining about lack of file permissions. I tried cranking the User Access Control / UAC setting down one level at a time and the problems finally went away when I shut it off completely. Is there any other way to fix this problem besides shutting it off totally? Thanks. I think hooovahh pointed out the correct way to deal with a situation on a Runtime system (Yes, the documentation of the feature could be better & you unlock for certain directories only!). However if you don't need the UAC (like for a standalone system nobody really cares about), just disable it entirely. I figure the latter one to be more like a 'workaround' solution, but you gain access to any file location without setting up all required directories manually. If your application has no predictable default behavior, it could be a pain to setup an installer for a system with UAC enabled. Quote Link to comment
Mike Le Posted October 15, 2013 Author Report Share Posted October 15, 2013 Where is this file located that you are trying to write to? I assume Program Files which Microsoft has said since Vista that area should be off limits for file writing. Originally, the file was being written to the root drive, C. I thought this might be causing the problem so I moved it to a different folder on the C drive. The problems persisted. The original file extension was ".config." I renamed it to ".txt" just to see what would happen and the file permission errors disappeared. It seems like there's some setting that prevents access to certain file extensions or unknown file extensions? Quote Link to comment
LogMAN Posted October 15, 2013 Report Share Posted October 15, 2013 Originally, the file was being written to the root drive, C. I thought this might be causing the problem so I moved it to a different folder on the C drive. The problems persisted. The original file extension was ".config." I renamed it to ".txt" just to see what would happen and the file permission errors disappeared. It seems like there's some setting that prevents access to certain file extensions or unknown file extensions? *.config files are Application Configuration Files which are treated as system files afaik. UAC will of course prevent you from editing system files, unless you have full read/write permission. It seems that the directory you use to store the files does not grant full read/write permission. Did you add your user name in the permission tab for that folder? Quote Link to comment
Mike Le Posted October 17, 2013 Author Report Share Posted October 17, 2013 *.config files are Application Configuration Files which are treated as system files afaik. UAC will of course prevent you from editing system files, unless you have full read/write permission. It seems that the directory you use to store the files does not grant full read/write permission. Did you add your user name in the permission tab for that folder? As best I could, I changed the Ownership and Permissions for the folder and files I was trying to edit. Unfortunately, it never seemed like the permissions "took." UAC would still prevent LabVIEW from editing the files. I tried setting the Owner to "Everyone" and setting full access permissions. Nothing worked and it was very frustrating. It's a new problem for me; I've used LabVIEW on other systems at work with Windows 7 and they've been fine. This is my personal machine, however. Quote Link to comment
LogMAN Posted October 17, 2013 Report Share Posted October 17, 2013 I have no solution for you, but this is how my machine works: 1) Creating a file from LabVIEW in C: will return an error Error 8 occured at Open/Create/Replace File in Untitled 1Possible reason(s):LabVIEW: File permission error. You do not have the correct permissions for the file.C:test.config 2) Create a subfolder (e.g.: 'C:New Folder') now writing the file to this location works perfectly fine. I did not have to change any properties for the folder at all. The UAC is set to 'standard'. And in the folder permissions, authenticated user are allowed to do everything except 'full access' and 'special rights' <-- these might be spelled differently, as I translate from my German system. It dosn't seem to matter if the file is *.config or *.txt. As it is a Windows OS, there are some possibilities that could cause such issues. So here is a list of things you could try: 1) Install all the latest service-packs & updates (Win7 SP1 must be installed, since there have been many issues before) 2) Check again if your account is really of 'Administrator' type (An account with 'User' rights can read the files, but not write) 3) Try running LabVIEW 'As Administrator' explicitly. (This must work) BTW, I always assume you are running an development system. Is that right, or are we talking about a Runtime system? For a Runtime system you need to unlock the executable at least. Quote Link to comment
Mike Le Posted October 19, 2013 Author Report Share Posted October 19, 2013 I'm running in the Development Environment, not an executable. I'll try explicitly running LabVIEW as an Administrator and see how that goes. Thanks for all the info. Quote Link to comment
ScottAD Posted April 1, 2014 Report Share Posted April 1, 2014 So I just ran into this error myself. I am just beginning to learn LabVIEW. I resolved the error by selecting the folder containing the file in question. Right click the folder and open the 'Properties' tab. Click on the check box for the "Read only (only applies to files in this folder). Rerun your vi and walla! Well at least walla for my problem. Hope it helps! Quote Link to comment
Hitesh Posted June 26, 2014 Report Share Posted June 26, 2014 I have no solution for you, but this is how my machine works: 1) Creating a file from LabVIEW in C: will return an error Error 8 occured at Open/Create/Replace File in Untitled 1Possible reason(s):LabVIEW: File permission error. You do not have the correct permissions for the file.C:test.config 2) Create a subfolder (e.g.: 'C:New Folder') now writing the file to this location works perfectly fine. I did not have to change any properties for the folder at all. The UAC is set to 'standard'. And in the folder permissions, authenticated user are allowed to do everything except 'full access' and 'special rights' <-- these might be spelled differently, as I translate from my German system. It dosn't seem to matter if the file is *.config or *.txt. As it is a Windows OS, there are some possibilities that could cause such issues. So here is a list of things you could try: 1) Install all the latest service-packs & updates (Win7 SP1 must be installed, since there have been many issues before) 2) Check again if your account is really of 'Administrator' type (An account with 'User' rights can read the files, but not write) 3) Try running LabVIEW 'As Administrator' explicitly. (This must work) BTW, I always assume you are running an development system. Is that right, or are we talking about a Runtime system? For a Runtime system you need to unlock the executable at least. Brilliant, Creating a Subfolder in C works.. and It's good in a way to create a subfolder ... thanks.. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.