We just virtualized a Windows server in Azure and everything in working fine on Client side, but we are not being able to solve the indexing search problem.
When you have a local drive, Windows can index the path and searches works fine using Windows menu/search box in task bar. But for shared drives it seems to fail.
In Windows Explorer the search pretends to work, but it takes forever to find a file or folder. And sometimes it just won't move anywhere. So it is not an option for users since them are used to search using menu bar.
We have tried to change drive properties in Right button to Shared Driver > "Allow files on this drive to have contents indexed in addition to file properties, but it was already enabled.
When we try to disable it, it prompts an error saying that the user doesn't have permission to do it, but it does anyway. And when we try to re-enable, the message prompts again, but it is enabled with no problem at all. But once again, nothing changes and Initial Menu Search just won't work.
Does anyone knows if there is a solution for that?
For me it seems to be an server setup since I see that permission error, but, as far as I know, if the shared driver is already mounted, I can't see a reason why Windows can't index it.
Ps.1: In the shared drive security tab, the System has full permissions.
Ps.2: If there is a solution for this, is that possible to solve it on the Windows server Side so we won't need to access client by client to change it manually?
enter image description here
Please check the following setting and see.
1.First thing is to check network location is being indexed. open File Explorer right-click on the mapped network drive that you need to index, then select the Properties and Make sure that, the Allow Files on this Drive to Have Contents Indexed checkbox is selected.
You have already done this step
2.try to check the search options for network drive in file explorer, go to view tab>>click on Options Icon and choose the change folder and search option menu it will open the folder options dialog box and select search tab and make sure first option is not selected
3.check server side Indexing
4.we need to make sure search service needs to be running.
Open services.msc check for the wndows search service and try to restart the service.
5.Go to Settings on the Windows 10 desktop, then click on Search, followed by Searching Windows scroll down and try to run the indexer troubleshooter
Reference https://learn.microsoft.com/en-us/troubleshoot/windows-client/shell-experience/fix-problems-in-windows-search
Related
After installing XAMPP to Windows 10 (all default/recommended installation attributes), I now have an issue changing its configuration after opening it.
Error: Cannot create file "C:\xampp\xampp-control.ini".
Access is denied
Clicking Save to a change in Configuration of Control Panel:
This "Configuration of Control Panel" box opens after clicking the "Config" button at the top right of the running XAMPP app:
I've tried a suggestion to run the XAMPP app with Administrator (elevated) access… but that seems like a major security issue, considering I don't know exactly what XAMPP would or could do with my files that require that permission, whether intended by the people who run XAMPP or not.
I've tried re-installing to another folder, like to C:\Users\Me, or a sub-folder like Documents or a custom one, but I just got different permissions issues that I struggled to figure out.
If you know a solution that worked for you, that avoided running XAMPP with Admin privileges, please let me know. I've gone through a handful of seemingly-related questions here but they seem to be related to MySQL/PHP questions and not Windows file system permissions.
I found a solution after noticing that the file already existed from apparently a past workaround I tried with running XAMPP as Admin... based on the permissions of the file being different than its parent folder. I discovered this by right-clicking the xampp folder or the xampp-control.ini file then selecting Properties and clicking the Security tab, then clicking into each attached user account's permissions.
So, my C:\xampp folder has these permissions: for Admin, basically full access; for my user account, Read, Execute, and Write.
The xampp-control.ini file has only Admin permissions; my user account is not attached to it.
Adding my user account to the xampp-control.ini file's Security, and adding Write permission then allowed XAMPP's config panel to save my changes.
Note that I typed my username into the "Enter the object names to select" box, then clicked Check Names; this auto-populated my username reference (?), though I'm not sure how it would work if it finds multiple results. Then I could click OK to get back to the Permissions box to add "Modify" and "Write" for it. I'm completely OK giving my user account permission to modify and write to this file through the XAMPP app.
Now, that fixes that file for that scenario; now I'm wondering if there will be other permissions issues with other files, because I noticed some other files (that I checked randomly) don't all share the same permissions for my user account!
Maybe I should have instead modified the xampp folder's permissions recursively to give my user account Write and/or Modify access (I'm not sure of the difference, Windows permissions seem far more complicated to understand and use than Linux's and Mac's do).
I think the file permissions were all set by XAMPP during install; I don't know yet that expanding permissions on certain files will not create new problems...
I found a solution after noticing that error, here is my solution
go to xampp installation folder on the c drive
Xampp Destination
then find xammp control panel.exe
Xampp Control Panel
then right click and go to properties(or press ALT+ENTER)
Click Properties
then go to compatibility and enable Run this program as an administrator
Compatibility tab
Your Problem is now fixed
My company has Chrome with our custom extension running on windows machines.
Our goal is to launch chrome locally on our machines with our extension running at all times. Our users are constantly looking to uninstall our extension.
Our current approach is to utilize the ExtensionInstallForceList registry key. This sort of works:
Right now, one can still click into C:\WM_0.0 and delete the folder. Once the folder is deleted, this extension is gone.
So we tried the following:
Create a windows account "Client"
Assign "Client" to "Client Group"
Change the permission C:\WM_0.0 to Deny Write
Log out and login to the machine again as Client.
Once I login to my windows machine as Client, I can no longer load my extension:
I tried to change the folder's permission to Full Control for both Users and Client Group but I am still seeing this error in Chrome.
1. How can I load this extension successfully given my current set of circumstances?
2. Is there a better way to do this?
Last few days i have been working on building an application to hide folders(thanks to the paid versions of such softwares). After a heavy googling I zeroed into some shell script that would first create a folder and then rename the folder to "Control Panel.{21EC2020-3AEA-1069-A2DD-08002B30309D}". It would then hide this folder by using the command attrib -s -h Control Panel.{21EC2020-3AEA-1069-A2DD-08002B30309D}. The funda behind this is to make it a system folder and hide it. But if you would uncheck the Hide sytem folders in Folder option the control panel becomes visible. I would like to make this folder completely invisible as how the other folder protecting softwares do.
Can somebody throw some more light on this?
Thanks a ton...
Most folder hiding software works by implementing either an extension for Windows Explorer or a file system filter driver.
The first method means that certain items will not be visible when browsing folders in Windows via the UI, but will still be visible to other software and via the command prompt. For example, the Recycle Bin and Temporary Internet Files folders work this way.
The file system filter driver method proxies calls between Windows and the underlying file system and only allows certain requests through. This is similar to how virus scanners prevent access to infected files.
The general idea is that you hook the file system API's and filter out the file system entries you want to hide.
But JelloMonkey is right - this is rootkit behavior and you will get flagged as malicious by rootkit detectors for this kind of behavior. That's likely to get your entire directory quarantined or deleted.
I want to known who is locking a file on a network share.
Here is the problem : the network share is on a NAS, so I can't log on. I need a tool to find out remotely who is locking the file. It is not practical to reboot the NAS every time, because there are several users.
Handle.exe, Process Explorer and PsFile seems to be limited to files on the local machine, so they don't work for me.
Just in case someone looking for a solution to this for a Windows based system or NAS:
There is a built-in function in Windows that shows you what files on the local computer are open/locked by remote computer (which has the file open through a file share):
Select "Manage Computer" (Open "Computer Management")
click "Shared Folders"
choose "Open Files"
There you can even close the file forcefully.
On Windows 2008 R2 servers you have two means of viewing what files are open and closing those connections.
Via Share and Storage Management
Server Manager > Roles > File Services > Share and Storage Management > right-click on SaSM > Manage Open File
Via OpenFiles
CMD > Openfiles.exe /query /s SERVERNAME
See http://technet.microsoft.com/en-us/library/bb490961.aspx.
PsFile does work on remote machines. If my login account already has access to the remote share, I can just enter:
psfile \\remote-share
(replace "remote-share" with the name of your file server) and it will list every opened document on that share, along with who has it open, and the file ID if I want to force the file closed. For me, this is a really long list, but it can be narrowed down by entering part of a path:
psfile \\remote-share I:\\Human_Resources
This is kind of tricky, since in my case this remote share is mounted as Z: on my local machine, but psfile identifies paths as they are defined on the remote file server, which in my case is I: (yours will be different). I just had to comb through the results of my first psfile run to see some of the paths it returned and then run it again with a partial path to narrow down the results.
Optionally, PsFile will let you specify credentials for the remote share if you need to supply them for access.
Lastly, a little known tip: if someone clicks on a file in Windows Explorer and cuts or copies the file with the intent to paste it somewhere else, that act also places a lock on the file.
If its simply a case of knowing/seeing who is in a file at any particular time (and if you're using windows) just select the file 'view' as 'details', i.e. rather than Thumbnails, tiles or icons etc. Once in 'details' view, by default you will be shown;
- File name
- Size
- Type, and
- Date modified
All you you need to do now is right click anywhere along said toolbar (file name, size, type etc...) and you will be given a list of other options that the toolbar can display.
Select 'Owner' and a new column will show the username of the person using the file or who originally created it if nobody else is using it.
This can be particularly useful when using a shared MS Access database.
The sessions are handled by the NAS device. What you are asking is dependant on the NAS device and nothing to do with windows. You would have to have a look into your NAS firmware to see to what it support. The only other way is sniff the packets and work it out yourself.
Partial answer: With Process Explorer, you can view handles on a network share opened from your machine.
Use the Menu "Find Handle" and then you can type a path like this
\Device\LanmanRedirector\server\share\
sounds like you have the same problem i tried to solve here. in my case, it's a Linux fileserver (running samba, of course), so i can log in and see what process is locking the file; unfortunately, i haven't found how to close it without killing the responsible session. AFAICT, the windows client 'thinks' it's closed; but didn't bother telling the fileserver.
Close the file e:\gestion\yourfile.dat, open by any user (/a *)
openfiles /disconnect /a * /op "e:\gestion\yourfile.dat"
more in:
http://dosprompt.info/commands/openfiles.asp
This problem crops up every now and then at work. Our build machine can have it's files accessed via a normal windows file share. If someone browses a folder remotely on the machine, and leaves the window open overnight, then the build fails (as it has done now). The explorer window left opened points at one of the sub folders in the source tree. The build deletes the source, and does a clean checkout before building. The delete is failing.
Right now, I'd like to get the build to work. I'm logged in from home, and I'd rather not reboot the build machine. I'm unable to get hold of the person whose machine is looking and the files, and I can't remotely reboot their machine.
When a windows share has a lock, the locking process is System, so I don't think I can kill it, as with normal locks.
Does anyone know a way to release the lock on a shared folder without having to reboot the machine?
If you are admin on the server sharing the file over the network, you can use the Windows in-built feature:
Start → My Computer → Right-click → Manage gets you to the Computer
Management console
In the left nav, navigate to Systems Tools → Shared Folders
You can view Shares, Sessions & Open Files here. This allows you to find out who has opened which files from which workstations.
Right-click on an item in the list to be able to remove the file lock.
Hope this helps.
Found a solution.
Find the process using Process Explorer:
Download and extract procexp.exe
In Process Explorer use the "Find Handle or DLL..." command from the "Find" menu
Enter in the name of the directory which is having trouble deleting
A list of open files which match that name should be shown. Take some guesses and find which one is failing to be deleted. If the file is locked by a windows share, the process holding the file will be System
Note down the directory which was left open
Download and install the Unlocker (Warning: Link removed, as it contains malware)
Install Unlocker, disabling the option for Explorer extensions and other junk
Unlock the directory
Open up a cmd window, and navigate to C:\Program Files\Unlocker
From the cmd window, run Unlocker.exe "the-path-to-the-locked-folder"
A dialog will pop up confirming the lock release. Use the unlock button to unlock the file
Now the directory should be unlocked, and can now be deleted.
Try Process Hacker:
https://wj32.org/processhacker/
Process hacker is like Process Explorer on steroids.
To find the offending process, press CTRL+F or click the "Find Handles of DLLs" button and search for the file name.
Once you find the file in the find handles dialog, you can simply right click the file there and choose "close". (at least for v2.39.124)
Older versions had a "terminator" option in the context menu of the process.
Right click on the offending process --> Miscellaneous --> Terminator --> Select termination techniques. Note that some are possibly dangerous and may have unintended consequences.
I've had similar problems, and none of these suggestions I've seen above look suitable for automated overnight builds (as the original poster implied) because they all require manual effort to hunt down and kill the locks.
The only method I've tried that seems to work reliably is to remove the share itself, make the build, then add the share back. Here's one way of removing the share automatically:
D:\Projects>net share Projects /DELETE /Y
Users have open files on Projects. Continuing the operation will force the files closed.
Projects was deleted successfully.
(NOTE: Creating the share again automatically can be a pain if the privilege groups you need to give it are messy.)
The way i do it is by using both OpenFiles.exe and Handle.exe
You can run them in any order and you will have your resource fully unlocked.
OpenFiles: to disconnect File Sharing sessions
Handle.exe: to release any open handles (don't try to close handles belonging to pid4, since that's the system process)
You can automate this by using powershell, batch, or any language of your choice.
Another option is, starting from Windows Vista, to use the Windows tool built into the system:
monitor resources: perfmon.exe /res
Extracted from: Http://www.sysadmit.com/2017/06/windows-how-to-know-that-process-has-open-a-file.html