I have a problem with Onlyoffice showing an error when I try to save any document.
The issue says that the file I try to save is already accessed by another program, I have no permissions to the folder or there's no space on my drive. The document is new, just getting created now via Onlyoffice so it can't be locked by another all. I have 230GB free on this c:\ partition and I try to save to a desktop of my user. And I have an admin role. So none of these 3 reasons is right.
It's a fresh install on Windows 10 x64 logged in as a user belonging to the Administrators group. So really not sure why it would have any problems with the permissions... Could anyone from the Onlyoffice possibly assist?
I want to use Onlyoffice as it's a great alternative to the other main office-suite products that I find overpriced.
Thanks
It's a fresh install on Windows 10 x64 logged in as a user belonging
to the Administrators group.
Do you have any AV software installed? If yes, please try saving the file with the antivirus disabled.
Related
I am trying to install Xampp win32-1.8.2 on Windows 8.1. I get a message saying" Because an activated user account User Account on your system some functions of XAMPP are possibly restricted." I've tried to change the user account control settings but still the warning is there. And the APACHE does not start. I've also disabled my IIS but still, its not working. What should I do? Thanks.
There are two things you need to check:
Ensure that your user account has administrator privilege.
Disable UAC (User Account Control) as it restricts certain administrative function needed to run a web server.
To ensure that your user account has administrator privilege, run lusrmgr.msc from the Windows Start > Run menu to bring up the Local Users and Groups Windows. Double-click on your user account that appears under Users, and verifies that it is a member of Administrators.
To disable UAC (as an administrator), from Control Panel:
Type UAC in the search field in the upper right corner.
Click Change User Account Control settings in the search results.
Drag the slider down to Never notifyand click OK.
open up the User Accounts window from Control Panel. Click on the Turn User Account Control on or off option, and un-check the checkbox.
Alternately, if you don't want to disable UAC, you will have to install XAMPP in a different folder, outside of C:\Program Files (x86), such as C:\xampp.
You can solve the issue by
Ignore the warning and Install XAMPP directly under C:/ folder. It will solve your issue
You can deactivate the UAC which i don't recommend. It's makes your PC less secure.
As ivan.sim writes in his answer
Ensure that your user account has administrator privilege.
Disable UAC(User Account Control) as it restricts certain administrative function needed to run a web server.
Install in C://xampp.
Problem with the correct answer is in the explanation of point 2., and magicandre1981 writes more about it
Moving the slider down doesn't completely disable UAC since Windows 8.
This is changed compared to Windows 7, because the new Store apps
require an active UAC. With UAC off, they no longer run.
How can we then disable UAC and install XAMPP?
Easy. Go to Registry Editor and navigate to
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
Right click EnableLUA and modify the Value data to 0.
Then restart your computer and you're ready to install XAMPP.
To disable UAC (as an administrator), from Control Panel:
Type UAC in the search button in your windows the upper right corner.
Click the (Change User Account Control settings) in the search results.
Drag the slider down and select Never notify and click OK.it will work.
There's nothing to be worried upon for this. Like other servers, install xampp somewhere outside of the default Program Files folder of Windows. It shall work fine.
I previously had wamp server installed on my machine and i never understood why wamp server installs itself outside of the default directory. Xampp cleared this, now i have both the servers lying outside the Program Files folder and are running fine.
I don't know if you are still having this problem, but I had the same problem and had a different fix than what was listed in the other answer. I did install XAMPP under C:\xampp\, and my user is an admin, but there was also something else.
I had to manually go give my user full access to the C:\Users\XAMPP\ directory. By default (at least on my machine) Windows did not give my admin user rights to this new user's directory, but this is where XAMPP stores all of it's config files. Once I gave myself full access to this, everything worked perfectly.
Hope this helps!
UPDATE!
In retrospect, I think that I must have accidentally typed in "C:\Users\XAMPP\" as the install folder during the installation process. So I think the most important thing is to make sure that the user you are actually signed into Windows as when you start XAMPP has full access to the folder that it was actually installed to.
I have faced the same issue when I tried to install xampp on windows 8.1. The problem in my system was there was no password for the current logged in user account. After creating the password then I tried to install xampp. It installed without any issue. Hope it helps someone in the feature.
You can solve this problem by installing xampp in different Drive .Instead of C Drive .
Run win+R and type msconfig
Then at tools box launch UAC
Then set it on the lowest level
Then press ok and continue your setup
Finish
change User Account Control setting via control panel
step 1 -: Go to control panel
step 2-: select 'user Accounts'
step 3-: select 'User Accounts' (Control Panel\User Accounts\User Accounts)
step 4 -: select 'Change User Account Control settings'
step 5 -: Drag the slider down to Never notify and after click ok.
I have problem printing reports to PDF through bullzip from Navision Application Server (1) if user is not in Local Admin group (2). Only under both conditions.
In Nav code I'm doing the following: init bullzip automation object (set all parameters to suppress GUI), run report to print document to virtual bullzip printer, catch output file. Thats it. Straight as a rail.
I have two environments: Windows Server 2008 and Windows 7 (different versions of Nav, but this is changing nothing). On Windows 7 it just do nothing (but works if user is admin). On server I can see error in Event Log (translated to English)
Faulting application gui.exe, version 9.8.0.1599, time stamp 0x517126dc, faulting module USER32.dll, version 6.0.6002.18541, time stamp 0x4ec3e39f, exception code 0xc0000142, fault offset 0x0006f52f, the process ID 0x3bc, application start time 0x01ce562238369fa9.
Gui.exe is a part of bullzip.
If I run the same code from Nav Classic Client, or from the same NAS launched in command line, or under local administrator account, or if i put the NAS user in local admin group - it works just fine.
To solve this problem i need to find out one of two and how to fix it:
What is the difference between local admin and regular user that could cause application to crash in non-interactive mode (service) under regular user account.
What is the difference in running NAS as service and as command line that could cause application to crash when run as service.
What I've tried so far: extend non-interactive desktop heap, give user all local privileges that admin have in gpedit. Not works. Don't know direction for further digging.
Any alternative free pdf printers advices are welcome.
This question is still actual. Though I've managed to setup PDF printing with PDFCreator. The tough part was to let several different NAS to print simultaneously. And now the setup have a bottleneck - PDFCreator's printing queue. With bullzip automations it could be avoided.
We've had some cases where third party DLL's have crashed within NAV due to permission restrictions.
The only effective way we could narrow down the files that it was trying to access was through using Process Monitor to try narrow down what was causing permission issues.
We found a folder within System32 to do with the System's Network Profile that some DLLs use. On that note, NAS's and such should be run under a domain account.
I think re-installing the application will do that,
Just make sure you are uninstalling each bullzip and ghost script,
Now Ghost script is tricky thing, if you are installing 32 bit over 64 then you are having problem,
refer this download link download appropriate version, install it,
and then install bullzip, after downloading new version from here
this will do..
then also if any problem(if you are using application for automation, you require new com object..) refer Forum, that explains most of application interface problems..
where you need to use public class PdfSettings with namespace bioPdf.
I hope this will help ..
I installed Microsoft SharePoint and Project PWA on Windows Server 2008 R2.
When I want to open Library in Windows Explorer, I randomly get an error:
Your client does not support opening this list with Windows Explorer
When I open IE it's working for 1st and 2nd time, but after some clicks it's not working anymore and I need to restart IE and then it normally works for couple of times.
When it not working through Sharepoint it also not works via \server\DavWWWRoot\PWA and oposite.
I'm searching through the web for weeks and didn't find any solution.
Do you have any idea what should be wrong here. Any suggestion is welcome :)
I had the same exact issue with Windows 7 and explorer view. The following steps resolved the issue for me:
First - be sure that the Web Client service is running (run>services.msc).
Next - In I.E. check Tools>Internet Options>Security>Local Intranet>Sites>Advanced and add the site that you want to use explorer view with.
This finally fixed it for me. I hope that you have already found a solution to this issue! I was surprised at how difficult it was to find a solution to this problem!
This error message is a symptom to a billion different problems.
I solved this problem when I realized my XP32 box could do this just fine with IE8. So I reverted to IE8 in 7x64 (you have to do it by uninstalling updates for IE until you're back at 8) and it didn't work. The build versions were different and on the 7x64 "about" box it said IE8 was using 256-bit cipher while in XP32 it had 128-bit. That to me was a hint that there may be 64-bit issues even when you run the 32-bit executable.
Then I found this hotfix so I reinstalled the windows update for IE10 and then installed this hotfix. Now I'm able to open the TeamCenter site in question in windows Explorer. IE10 reports it's version 10.0.9200.16686. I cannot guarantee that it was the hotfix alone (and not also the reinstallation of IE10) which fixed it. But I'm willing to bet it was the hotfix alone.
In XP I found it impossible to then map this network location to a drive letter, as mapping doesn't like URL's. However in Windows 7 you can transform the URL so that it is interpreted as a Windows share. If the URL of a given folder is of this form:
https://somesharepoint.com/folder1/folder2/folder3
you can also access it as
\\somesharepoint.com#SSL\DavWWWRoot\folder1\folder2\folder3
and, in this form, it can be mapped to a drive letter.
I do have issues at that point that even with IE10 open and logged in to the site I see some random time-out like problems and I get kicked off (and prompted to log in again in IE10). My situation is complicated because the site I'm accessing requires an Exostar token to log in, so I have to log in via website no matter what.
If it helps any one do the steps suggested above:
Make sure to use 32 bit internet explorer (program files (x86)/internet explorer).
Like was mentioned above Web client must be started.
You may also need to add your site to trusted sites in internet explorer.
Make sure enabled protected mode in internet options is disabled.
This is what finally fixed it for me: Check "Keep me signed in" on the login page. This was the key for me. Will not work without it checked in my case.
I had the same symptoms, and it turned out I don't have a root site collection. Creating one solved this for me.
Summarized the troubleshooting steps here:
http://letitknow.wordpress.com/2012/07/22/your-client-does-not-support-opening-this-list-with-windows-explorer-error/
There can be multiple reasons for it.
One could be using IE x64 version. It won't work there.
Secondly, check out this blog:
http://blogs.technet.com/b/asiasupp/archive/2011/06/13/error-message-quot-your-client-does-not-support-opening-this-list-with-windows-explorer-quot-when-you-try-to-quot-open-with-explorer-quot-on-a-sharepoint-document-library-in-office-365-site.aspx
I experienced the same problem as well.
And I found out that if none of the above options are working, and if you work in an organisation, maybe the proxy is blocking the "Open with Explorer" option.
I did the same, and removed the proxy and it worked just fine.
this fixed it for me ( however in windows server 2008 you may need to install desktop experience i think its called)
After you log into windows go into services then restart the WebClient then see if you can use explorer view without the error " your client does not support. blah blah blah" if it does work then. make a batch file that says:
net stop webclient
net start webclient
then make a scheduled tasks that runs that batch file at start up. Have it run as a user with administrative rights, make sure you tell it to run even if user is not logged in. it should prompt you for the password of the admin account you selected. this worked for me with windows 7.
I found online where the error can occur intermittently with SharePoint 2010, however I think the SharePoint version is irrelevant. They said the client polls for a SharePoint root site and that the error occurs if one isn't found.
We have not seen the error since I created a root site even though we’re only using WSS3. Our errors began when we changed clients to Windows 7. So in our case it sounds like the issue could be the root site polling due to an IE8 security change in Windows 7.
SOLUTION:
*you on x64 bit machine* so solution is that there is no problem but you are using the wrong IE shortcut.
There are different IE types you can use (just type Internet Explorer in start search bar) and you will see..
Internet Explorer (64-bit) - won't show any sharepoint add-ons
Internet Explorer (No Add-ons) - won't show any sharepoint add-ons
Internet Explorer - only this will show sharepoint add-ons and will
work so basically make sure you always use this version of IE
I need to install an application (SQL Server Denali, but this is irrelevant) and during the installation, I have a lot of problems with registry... a lot of pop-ups appear telling that i dont have permissions to modify that key of the registry.
I'm administration but seems that with some keys i dont have permission and i have to modify permissions manually. The problem is that there is a lot of registers giving problems.
What can I do? How can i add full control to all the keys of the registry?
I have Windows 7 64bits
Thanks
What's your OS on which you are trying to install?
I have seen security features on Windows 2008 and Windows 7 (which is good but can be annoying as seen by you on popups for permissions). Even though the local user is as administrator with which you are trying to install, on these systems its best to right click and choose "Run as Administrator"
Also you can choose to lower the security level on "user account control settings" (click on start menu button in Windows 7 / 2008) and in the search bar type uac, and lower the security to never notify and bring it back up after the installation.
Hope this helps...
I have a web site that I developed on Vista using Vb.net9. It makes a connection to Oracle. for the connection I use System.Data.OracleClient. It works fine on my machine, and our test server, but it does not work on the production server. We installed the Oracle Client 11 on the server. The error is System.Data.OracleClient requires Oracle client software version 8.1.7
We've tried, making a console app that opens the connection, connection runs fine, opens, displays a message and all is well there.
Then we make a simple web form, put it in the directory of the program, just a button, opens the connection, try..catch, grabs error, same error.
The console app was running under an Administrator, web site running under iwam. Is it possible that iwam has a different path?
I've run into this error dozens of times:
Cause
Security permissions were not properly set when the Oracle client was installed on Windows with NTFS. The result of this is that content of the ORACLE_HOME directory is not visible to Authenticated Users on the machine; this causes an error while the System.Data.OracleClient is communicating with the Oracle Connectivity software from ASP.NET using Authenticated User privileges.
Solution
To fix the problem you have to give the Authenticated Users group privilege to the Oracle Home directory.
Log on to Windows as a user with Administrator privileges.
Start Windows Explorer and navigate to the ORACLE_HOME folder.
Choose properties on the ORACLE_HOME folder.
Click the Security tab of the Properties window.
Click on Authenticated Users item in the Name list.
Un-check the Read and Execute box in the Permissions list under the Allow column.
Re-check the Read and Execute box under the Allow column.
Click the Advanced button and in the Permission Entries verify that Authenticated Users are listed with permission: Read & Execute, and Apply To: This folder, subfolders and files. If not, edit that line and make sure that Apply To drop-down box is set to This folder, subfolders and files. This should already be set properly but it is important that you verify it.
Click the OK button until you close out all of the security properties windows. The cursor may present the hour glass for a few seconds as it applies the permissions you just changed to all subfolders and files.
Reboot, to assure that the changes have taken effect.
Try your application again.
The author of this post (now deleted post) suggests checking your C:\Windows\System32 folder to make sure that the oci.dll exists there. Copying in the file from the Oracle home directory solved this problem for me.
Update 1: It is possible for different users to have different path. But its not the likely problem here. There is more chance that the user that the iwam user doesn't have permission to the oracle client directory.
Update 0: Its suppose to work. Check for environment variable ( That are needed to find the oracle client and tnsnames.ora ). Also, Maybe you have a 32/64 bit issues. Also, consider using the Oracle Data Provider for .NET ( search for odp.net)
Oracle Client version 11 cannot connect to 8i databases. You will need a client in version 10 at most.
When we first moved over to Vista with Oracle 10g, we experienced this issue when we installed the Oracle client on our Vista boxes, even when we were running with admin privileges during install.
Oracle brought out a new version of the 10g client (10.2.0.3) that was Vista compatible.
I do believe that this was after 11g was released, so it is possible that there is a 'Vista compatible' version for 11g also.
Why not use this: dotConnect for Oracle (formerly known as OraDirect .NET)?
It can be configured to not require an Oracle Client at all.
We have been using this in both Windows Services and ASP.NET Web Services and it works like a charm.
For me, the issue was some plugin in my Visual Studio started forcing my application into x64 64bit mode, so the Oracle driver wasn't being found as I had Oracle 32bit installed.
So if you are having this issue, try running Visual Studio in safemode (devenv /safemode).
I could find that it was looking in SYSWOW64 for the ic.dll file by using the ProcMon app by SysInternals/Microsoft.
Update: For me it was the Telerik JustTrace product that was causing the issue, it was probably hooking in and affecting the runtime version somehow to do tracing.
Update2: It's not just JustTrace causing an issue, JustMock is causing the same processor mode issue. JustMock is easier to fix though: Click JustMock-> Disable Profiler and then my web app's oracle driver runs in the correct CPU mode. This might be fixed by Telerik in the future.