I'm trying to use ICACLS in powershell to set a few permissions.
Does this ICACLS command also apply the permission onto childitems in the same run?
icacls "D:\Folder" /grant "Domain\ADGroup":(OI)(CI)RX
If so, is there a way to turn this off? Can't I set the permissions just on the parent folder?
I'm completely resetting each childitem afterwards anyway so that every messy permission/owner gets removed and each childitem inherits the correct permissions again.
But this would take the double amount of time if the previous command already runs through each childitem and applies the permission I specified.
No, the permissions are only applied to D:\Folder, but subfolders and files will inherit the permissions as you've specified.
If you'd used /T it would set the permissions on each and every file, so try to avoid that.
/t Performs the operation on all specified files in the current
directory and its subdirectories.
Icacls
Related
I have 3 hard drives. I would like to sync specific folders from each drive with MS OneDrive.
One hard-drive cannot hold all the files from all hard drives.
How can I do this with OneDrive?
What I have done in the past is use symlinks to sync everything to OneDrive, and maintain the folder structure I want. For example, when coding, I like to keep my source folders on the root of C:, so that I can easily access it from menus (C:\coding). So what I'll do is create a folder in OneDrive called coding then symlink it to the root of C: using cmd.exe
mklink /d "C:\Link\Location" "C:\Users\USERNAME\OneDrive\Path\To\Source\Folder"
mklink /d "C:\coding" "C:\Users\USERNAME\OneDrive\coding"
Elevated permissions are required to do this.
You can do this with as many folders as necessary. Just remember, the source folder HAS to be in OneDrive. If you have existing folders that you want to sync, move them all to OneDrive and then symlink them to where they originally were located. Example:
mklink /d "C:\Users\USERNAME\Documents" "C:\Users\USERNAME\OneDrive\Documents"
mklink /d "C:\Users\USERNAME\Desktop" "C:\Users\USERNAME\OneDrive\Desktop"
mklink /d "C:\Users\USERNAME\Favorites" "C:\Users\USERNAME\OneDrive\Favorites"
mklink /d "C:\Users\USERNAME\Desktop\Vacation Pics" "C:\Users\USERNAME\OneDrive\Vacation Pics"
mklink /d "C:\Whatever I want" "C:\Users\USERNAME\OneDrive\Whatever I want"
--edit--
There is also the application Link Shell Extension that I have found extremely useful. Full instructions are found at the link, but... It integrates with Windows' Explorer shell and adds an item to the context menu. You can right click a folder to select it as the symlink source, then left click in the directory you want the symlink to be located. I think it does other things as well, but this is all I use it for. FYI, it requires VCRedist 2005 if memory serves, and does not include that dependency bundled.
For now, MS OneDrive client application only supports one folder. You would need to move all your files into that one folder.
You also cannot use Windows Explorer Libraries as the OneDrive folder - since those are NOT really folders.
Directory links are also not supported in some versions of windows. (http://www.howtogeek.com/174765/how-to-sync-any-folder-with-skydrive-on-windows-8.1/)
The Solution
What I used in the end is SyncDriver - does everything you need from any folder:
http://syncdriver.com/
First you set up the one folder where all the online stuff will go. Then you add any folder - from any drive - and it all goes to OneDrive. Simple and easy to use.
You also have options to only sync in specific directions:
OneDrive => local
local => OneDrive
Bi-Directional
I am about to create a MSI package.
During the installation (launched e.g. via double-click on the MSI) some files contained in the MSI are deposited deeper under c:\ProgramData (resp. the CommonAppDataFolder), e.g. c:\ProgramData\myCompany\myApplication.
Later when the installed application is run by the user the application may need to modify these file.
The problem is that neither the running application nor the user e.g. via Windows Explorer has the right to modify any files under c:\ProgramData\myCompany\myApplication created during installation.
The files do not have a readonly attribute set.
The strange thing for me now is: If I install the MSI via msiexec /q /i then I have write permissions on these files.
My MSI is created with WiX, my os is Win 7, the user is member of the administrator group.
Can anyone tell me why that is so, and how I can gain write permissions to these files w/o having to use /q /i?
Thanks
Jan
EDIT 2014-03-24: Damned. I missed to specify the InstallPrivileges attribute on my element, I just didn't know about it.
Setting it to "limited" does not show up a UAC prompt when installing to ProgramData! And now the user / my application is allowed to overwrite files in the destination folder :)
I don't know why that behavior would be different regarding access to that folder unless you have a custom action that does something that is only in the UI sequence. That's the only functional difference I can think of - the UI sequence is suppressed in a silent install.
However the common app data folder is not normally writeable to limited users. I'm not sure how much you know about UAC, but it doesn't matter if the user running the program is an admin or not because by default admins run with limited privileges. If the app needs admin privilege to run then it needs building with an elevation manifest so it asks for elevation to admin privilege. Either that or run it as administrator from a shortcut.
Windows access control is extremely complicated to deal with. In every version of Windows there is something new and changed to deal with, and it looks like the default write access in ProgramData now includes some sort of special ACL / DACL. If this is indeed the problem you can apply new permissions there and open up for regular users to write. Please note that I am not quite aware of exactly what newer versions of Windows apply as default. The tool I generally use to set permissioning is subinacl.exe. A real handful of a tool with a command line that can scare the most experienced system administrators. Some command line samples are here. You can also use the LockPermissions table in MSI, but somehow there are some issues with how these permissions are applied to the file system object. subinacl.exe is more complex, and more capable.
More on file and folder permissioning:
http://technet.microsoft.com/en-us/library/bb727008.aspx
http://support.microsoft.com/kb/308419
With regards to where you should put different types of files on the system, please check this thread.
I'm currently refining and updating my offline virus database updater for Malwarebytes. It's simply all the Malwarebytes data from C:\ProgramData\Malwarebytes (virus database, build number, etc) inside an SFX .exe archive set to run a batch file after successful extraction.
The Problem
My existing updater works by copying each file with individual xcopy commands, but this time I want it to simply copy the whole folder. But when trying to xcopy to C:\ProgramData, I get "Access denied" for everything.
This occurs even though I'm using the /y and /o switches and running the .exe as Administrator (from the context menu) to achieve elevated permissions. I know that I'm hitting the right directory and that the update does work with a manual copy and paste of the folder.
Is it just that it's not possible to command-copy a folder to ProgramData in Windows 7?
Extra Information
Inside the SFX .exe archive, I have a folder called "Malwarebytes" and a batch file. This is the only relevant segment of the batch file (I have independently confirmed that the rest of it works):
xcopy "Malwarebytes" "C:\ProgramData\Malwarebytes"\ /y /s /c /h /o
Odd.. It just started working.
The only idea I have for this is that when I was trying this, I was trying it with an activated version of Malwarebytes, which means that it was running a service in the background, whereas this time I was not using an activated Malwarebytes'.
This could have possibly been denying access to the files because they were in use.
I don't know. Thanks anyway, guys.
I have encountered this problem without pin pointing the problem However I used Robocopy instead. So simply replace xcopy with Robocopy with appropriate switches and it should work ...
In the diagnostics sections in textpattern, it's giving me the error:
"File directory path is not writable:...html/textpattern/files" (took out beginning of path)
I changed the permissions for the textpattern folder, and the folder named "files", which is in the root folder not in the textpattern folder, but it's still giving the error. Do I need to change permissions for all enclosed items of the textattern folder and not just the folder itself?
Maybe I got you wrong but I suppose you simply have to change the path to the files folder in your admin panel from "…html/textpattern/files" to "…/html/files".
Assuming you're on a *nix system...
It sounds like you want to change the permissions recursively.
A quick fix might be to change the permissions like so:
chmod -R 777 html/textpattern
This command will go through every folder and file and change its permissions (the -R turns on the recursive bit).
Warning, this is very broad and not a good idea for production.
A better approach would be to change the permissions at a finer level of granularity. Google for "Linux file permissions" or type man chown at the shell.
can someone help me with a dos script to move all files from one location to another location
move <sourcepath>\*.* <destpath>
IE, if you wanted to move all files from c:\test\ to c:\test2
move c:\test\*.* c:\test2
if you want to suppress the prompt to overwrite files
move /Y c:\test\*.* c:\test2
If you want to move from the current directory, you can specify just the *.*. Also you can do relative paths. So if you want to move the current directory's files up one directory, you'd do
move *.* ..
.. being the shortcut for "up one directory"
If it's across the network, you can use a UNC path to authenticate as the user you're logged in as or map a drive (using the NET USE command) to specify a username/password on the remote computer, then copy using that drive letter. You can then delete the drive letter after you're done. UNC paths look like \\computer\share\folder\file.txt
I think this one
C:\> MOVE /Y *.* C:\Destination
should be corrected.
Use Robocopy. In Windows 7 and Windows Server 2008 R2 you can even run it multi-threaded using the /MT[:n] switch. From my daily "sync-before-shutdown" script:
Robocopy "d:\dev" "\\dolores\backups\carrie\dev" /e /MT /njh /njs /nc /np /nfl /ndl
(all the /n.. switches suppress console output which helps to speed up the copying process).
To move the files, use either /MOV or /MOVE (to move all subfolders) instead of /E.