I know there are a lot of cases close to this, but I have not found any that matches my circumstances.
Quite a few of our clients backup large quantities of data using cygwin.
The general environment is:
A windows based virtual domain controller (host is esxi, but that is irrelevant)
The backup is going to an external encrypted raid device. which the system sees as a normal usb attached hard disk.
OS tends to mainly be sbs2011 / 08, in some rare cases sbs03.
Cygwin, usually the latest version as it is kept up to date. and its snapshot package.
The rsnapshot conf file is not really changed from its origianl state with the exception of target and destination, and some exclusions.
The backup is triggered by a batch, which starts cygwins rsnapshot rsync process creating a backup from the windows server to the attached storage in (hourly x2 daily x5 weekly x4 monthlyx6 backups.)
The source files are rsynced to the destination. the original order of the permissions is not preserved but the necessary permissions are kept, ie source has the group and a user admin with full access, the target has both but with special permissions, and within special, full access is granted.
When rsnapshot moves hourly0 to hourly1 it completes. all the files are linked properly. but it takes a long time due to every file getting a "could not link (cygdrive/x/x/hourly.0/path to file/file /cygdrive/x/x/hourly.1/path to file/file Permission denied)
args is commented out because anything put into args ie -av etc does not work and nore does it need to as the destination in another way does have administratoren and admin with full permissions.
cygwin is installed using admin on the admin account, task scheduler is set to admin, and the tasks are run by the admin account with full access.
The backing up process works. I believe the issue lies in the destination, I can understand that it could be related to issues between posix and acl but do not believe it is the cause as again, the permissions are granted.
So I am asking the most experienced out there, if you have any ideas, things to try, change. Please could you let me know clearly.
Kindest regards and appreciation.
Dan
Related
I have 2 machines, one is Windows 10 and the other is Windows 7, recently whenever I download a file on Windows 10 machine directly on my External Hard Disk and detach it from that machine and try to attach it to windows 7 machine, I have no access to any of the downloaded files it gives me access denied. I can access folders and see the files are present but cannot open them.
To solve this issue I have to manually assign permission to each files by first taking ownership of that file for "Everyone" account and then assigning "Everyone" full control.
I have tried to take the ownership of the folder but receives the error of access denied for each files when selecting the option of "Permission Inheritance for files and Sub Folder"
I have even tried to write a PowerShell to assign permission but the situation does not change it returns with an access denied error. FYI, PowerShell window is opened as Administrator by selecting Run as administrator.
Even if I run the intended application as Administrator it will still not work it will still give me Access Denied.
The only workaround I found was to perform the above actions of individual file ownership and permission assignment.
It would of great help is someone can provide a permanent solution to this issue.
BTW, The external hard drive which I use is WD drive and its with me for than 5 year now and never encounter this issue in the past.
And the files in questions are Photos, videos, documents and mp3.
This is neither a PowerShell nor a programming issue, so the question would be more suitable for SuperUser.
Creating a file on removeable media on one system and then trying to access that same file on a different system will normally fail unless you took precautions to make the data accessible from other systems. That is because even though users and groups may have the same name on both systems they still have different SIDs (which is what the system actually uses to decide whether access is or isn't allowed).
To grant a user on a different system access to the file you have to take ownership and grant the user(s) on that system access.
takeown /f x:\ /a /r /d y
icacls x:\ /reset /t /c
icacls x:\ /grant administrators:(oi)(ci)f username:(oi)(ci)rx
Note that adjusting ownership and permissions of a single file usually does not suffice. The user must be able to at least traverse the entire path to that file. Similarly taking ownership and adjusting permissions on a folder may not suffice unless the files in that folder inherit their permissions from the folder. If they don't you need to take ownership of the files and adjust their permissions as well.
The above 3 commands recursively take ownership of everything on drive X:, reset permissions to enable inheritance, and grant access to the Administrators group (full control) and the user "username" (read and execute).
With that said, you can prepare permissions so that files are accessible on different systems without the need to take ownership and adjusting permissions on the target system. There are a number of principals and groups that have the same well-known SID on all Windows systems, e.g.
Everyone (S-1-1-0)
Administrators (S-1-5-32-544)
Users (S-1-5-32-545)
Authenticated Users (S-1-5-11)
Granting access for instance to the group "Users" should make your data accessible across different systems.
Install a separate hard drive or prepare a separate partition for each operating system.
Install the operating systems. For example, if your PC has Windows 8.1, install Windows 10 onto the other hard drive or partition.
Reboot the PC. The boot menus should appear with both operating systems listed.
If both operating systems aren't listed:
Open a command line, either as an administrator from inside Windows, or by booting to a command line using the Windows installation disk and presssing Shift+F10, or by booting to Windows PE (WinPE: Create USB Bootable drive).
Add boot options for a Windows operating system.
Bcdboot D:\Windows
Reboot the PC. Now, the boot menu will show both menu options.
Let’s give permission to the file and check if that helps. Follow these steps to give permission to the drive.
Right-click on the file which you’re unable to access and select Properties.
Click on the ‘Security’ tab and under ‘Group or user names’ click on ‘Edit’.
Click on ‘Add’ and type ‘everyone’.
Click on ‘Check names’ and then click ‘OK’.
Select ‘everyone’ and under ‘Allow’ select ‘Full control’ and click
on ‘Apply’ and Click ‘Ok’.
Hope this helps.
I'm a programmer not an admin. I significantly modified an old program written in 1997 to run under Windows XP ~7 years ago. At that time, I rewrote in VC++ 2005. The local production network has been updated to Win7. Program updated to VC++ 2010.
Problem: Program runs in new environment but only if user has admin privileges. Without, needed files cannot be accessed. Attempted Fix has been to give user group access to the needed files. Users can access the files "by hand" but program still fails.
Is there a way to give the application admin privileges so that it can access the files?
Not acceptable is allowing users to run as admin. We have to operate under DoD constraints. Is there something I as the guy working on the application can do? If not, what is the solution?
Recap: problem was a large number of scratch files which, in the original application, were being written to the C:\ root directory. The solution was to use "getenv_s" to obtain the user's directory via an environment variable. The pathname was modified such that the string returned from "getenv_s" was concatenated with the scratch file name. Laborious but problem solved.
The huge difference between XP and Windows 7 is the access system (user access control entered with Vista and was further refined in 7). In theory you could run the application as an admin user, or provide a service that would access the necessary system components and files as an admin user. But there isn't a way of giving an application itself extra permissions.
Your other option is to find out what specifically is causing the problem and correct that in your application. Chances are this is a system file or the like.
I am using C# with .net 2.0
I am saving my program data in a file under: C:\ProgramData\MyProgramName\fileName.xml
After installing and running my application one time I uninstalled it (during uninstallation I'm removing all the files from "program data") and then I reinstall the application, and ran it.
The strange thing is that my application started as if the files in program data existed - means, I had old data in my app even though the data file was deleted.
When running:
File.Exists("C:\ProgramData\MyProgramName\fileName.xml")
I got "true" even though I knew for sure that the file does not exist.
The thing became stranger when I ran the application as admin and then the file didn't exist.
After a research, I found out that when running my application with no admin privileges instead of getting:
C:\ProgramData\MyProgramName\fileName.xml
I get
C:\Users\userName\AppData\Local\VirtualStore\ProgramData\MyProgramName\fileName.xml
and indeed there was a file that existed from the previous installation (that I obviously didn't delete, because I didn't know it existed).
So just guide me how could I stop this when apps running with no admin right.
I do not want to create any file automatically in VirtualStore folder. Please discuss all the possible ways to stop this.
First, ask yourself, do this need to be globally saved for all users?
If it doesn't have to be, save the file in Application Data instead, you can get the path with Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData), it should always reliably expand to C:\Users\Username\AppData\Roaming\. Do note that this path is unique for each user though.
If you have to, you're out of luck. There is no reliable way to store application data for all users without admin rights (or UAC) on any Windows post-XP that's not extremely hacky, like storing your data in the Public user (which may or may not be possible, I can't check right now).
An approach to solving this is to use the Environment.SpecialFolder.CommonApplicationData location, but with some very important caveats & setup.
CommonApplicationData is
The directory that serves as a common repository for
application-specific data that is used by all users.
This location is described further here and here.
Important requirements and restrictions are given in another SO answer: https://stackoverflow.com/a/22107884/3195477
which said in part:
The recommended solution is for your installer to create a sub
directory of C:\ProgramData for your shared storage. And that sub
directory must be given a permissive ACL by the installation program.
That is what grants the desired access to all standard users.
Otherwise the program running with standard user permission will still not be all equally able to read/write files in that location for all users.
I found a work around for this issue when transferring a very old win32 app to windows 7 & 10. The program wrote to a database on C:\Program Files... but the OS auto changed the path to virtual store. However the database was required globally. By changing compatablilty mode to Windows 95 or XP SP2 and always running as administrator the database was worked on directly in C:\Program Files\etc.
There are security implications for this and the box was removed from all networks and adapters disabled etc.
I have an EMC Celerra filesystem shared between Windows and Linux Clients. User A on a Windows client creates a directory and set of files and User B on a Linux client is to modify and/or delete these files; however the files and directory to not have write permission for anyone other than the original owner. If this was on a Linux NFS share, I could use umask to set the permissions to allow group write permissions. Is there a way for the Windows client to set the correct permissions on the files when created? Or is there a way to do this on the EMC Celerra? I can write a script to perform a chmod on the Linux side but wanted to avoid this if possible.
Thank you,
JP20036
Old question, but if you are managing the Celerra share via Windows you can set permissions there and you can set it so that any user has wright permissions pretty easily from the share creation wizard. Try recreating the share and coming at the permissions that way (obviously OP is no longer looking for an answer, but just in case anyone googles it).
I have content on a portable HDD that is to be shared between 2 or more computers, but none of the computers are connected to a domain (none exists). I want to give permissions to the content in such a way that the permissions remain the same across all my computers, irrespective of which computer I connect the HDD to and irrespective of which user account was used to set the permissions.
For example, I want the built-in Administrators group (SID: S-1-5-32-544) to have Full Control of a file on the portable HDD, irrespective of the computer it is connected to (I am aware this constitutes a big security hole, but so long as the drive doesn't get stolen, I am ok with it. Anyway, once an attacker has physical access to a drive, all bets are off.).
Problem I am trying to solve is this: I connect the HDD to computer1, set all permissions, disconnect. Then I connect the HDD to computer2, and suddenly the permissions aren't right for the user on this computer since the SIDs are different (both in terms of permissions and ownership of content).
If you want the Administrators group to have full control, just set it that way. In Windows XP Pro or some other system that gives you a Security tab in Properties, use it. In the drive's security properties, add Administrators (if it's not already there), and in the privileges for Administrators give full control and enable all inheritance. You just have to set that on one machine and then other NT-based Windows PCs will obey the settings.
If you can't find one Pro system to use for that setting, then you'll have to learn the cacls command line. Fortunately you still just have to do it once. Oops. You'll have to do it n times where the first (n-1) times are various mistakes, but you just have to get it right once.
The permission scheme you choose for your HDD depends on the filesystem you've formatted the drive with. Different filesystems specify permissions differently and have to be treated separately.
Why are you using permissions at all? If someone gets the drive then they have access. Instead, just use something like truecrypt to protect everything, and give everyone permissions to everything in the truecrypt volume.