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).
Related
I have an issue with mounting Windows file share in Cygwin.
We have Windows file share which is using NFS to share content. I was assigned to install Cygwin on it so some application can connect over SFTP to that server.
Now they need to access the shared folder from that application and the app would pull data from that folder.The thing is that the folder is Windows shared folder (exmple; \server\photos). the current Windows users need to be able to connect to that share (it is mapped to their M drive) and the app need to connect to SFTP and pull the data from there.
My idea was to mount that NFS share in Cygwin and set it as /home directory so when the app connects, it automatically goes there.
My questions are: is this possible, and does anyone know any better solutions?
I am open for all suggestions.
Thank you.
Cygwin views the top of its directory tree / to be within the Windows directory C:\cygwin64 (or whatever its installation directory was). As a result, you are unable to move above that point in the filesystem from a Cygwin shell. The solution is to go through Cygwin's directory /cygdrive, which is automatically set up as the access point where all Windows disk drives are mounted. If your shared folder is mounted in Windows as M:, you should be able to access it in Cygwin as /cygdrive/m without any additional work.
As far as setting it up as /home, you might be able to create a symbolic link from /home to /cygdrive/m if that is what you need.
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
I'm writing a desktop app and need a folder which...
Exists in Windows 7 and Vista
Is common to all users (for store config data).
Application can save data on it, without Admin privileges (not like "ProgramData").
is standard (I don't want to create another app specific folder in "C:", the Desktop or other place alike.)
"Program Files" is not an option, of course.
Can you suggest an appropriate folder, or better use the Registry?
The recommended way to do this is to create a folder at install time, dedicated to your application, underneath "ProgramData" (i.e. CSIDL_COMMON_APPDATA/FOLDERID_ProgramData).
As you already know, the CSIDL_COMMON_APPDATA folder is read only for standard users. So your install program needs to give the folder that it creates an ACL that permits the access that you require.
This is the solution that meets all the criteria laid out in your bullet points.
You mention the registry. There is no area of the registry that is shared between all users and yet writeable by standard users. Whilst you can use ACLs to grant more permissive access rights to the registry, it is really not the done thing. Please forget that I even mentioned this possibility!
IF your app is .NET then use CommonApplicationData - you can get the real location by calling GetFolderPath.
EDIT - as per comments:
You need to setup ACL correctly - for sample source code on how to do this see http://www.codeproject.com/Tips/61987/Allow-write-modify-access-to-CommonApplicationData
What about Public User directories? For Example: C:\Users\Public\Libraries or C:\Users\Public\Documents
I've noticed these folder on several of my Windows 7 machines. I'm not sure if it is always there, but might be an option. I was hoping for something like an %appdata% for the Public User, but the closest thing I found was Public\Libraries.
(As a side note, it appears C:\Users\Public\Desktop does require admin to write to.)
what about using %APPDATA%/Company/Product for the directory?
I have a D-Link DNS-323 NAS, running some sort of Linux as its OS.
I map a volume as a share in Windows Vista (Ultimate SP2). There are some directories and files on that share that I cannot change/delete - no matter what I try. Trying all of Windows security/permissions dialogs don't work, as the files owner is "Unix/root" and all other Windows users have read-only permissions.
I managed to ssh into the OS and verified that these files belong to 'root' - the user under which I log in, and all the other files (the ones I can change) belong to 'nobody'.
All fine and well, while I'm in ssh, I can always "chmod +w" the files, or "chown nobody". But my question is this: how can I make my Windows user (let's call him 'admin') impersonate 'root' on the Linux, so I can simply manipulate files from Windows, without resorting to ssh?
In other words, and to make the whole question plainer: how do you tell your OS that a certain user on Windows is a certain user on linux? (that way, I can have 'admin' be 'root').
Thanks in advance,
Guy
Samba can do something like you've said. it basically emulates windows compatible permissions on a linux box..
Assuming the NAS is running samba (almost certainly), there should be a samba config file somewhere in /etc. But I don't know if it would be editable.
The remapping between windows/Linux and permissions is all done on the server (samba) side.
There are a lot of Samba faqs about this.
Cygwin can do that.
EDIT:
The cacls command in Windows looks like it does what you want.
I'm trying to build a Windows installer using Nullsoft Install System that requires installation by an Administrator. The installer makes a "logs" directory. Since regular users can run this application, that directory needs to be writable by regular users. How do I specify that all users should have permission to have write access to that directory in the NSIS script language?
I admit that this sounds a like a sort of bad idea, but the application is just an internal app used by only a few people on a private network. I just need the log files saved so that I can see why the app is broken if something bad happens. The users can't be made administrator.
Use the AccessControl plugin and then add this to the script, where the "logs" directory is in the install directory.
AccessControl::GrantOnFile "$INSTDIR\logs" "(BU)" "FullAccess"
That gives full access to the folder for all users.
AccessControl::GrantOnFile "<folder>" "(BU)" "FullAccess" didn't work for me on a Windows Server 2008 machine. Instead I had to use this one:
AccessControl::GrantOnFile "<folder>" "(S-1-5-32-545)" "FullAccess"
S-1-5-32-545 is equivalent to "Users" according to Microsoft Support: Well-known security identifiers in Windows operating systems.
Instead of changing the permissions on directories under Program Files, why not put the logs in a location that is writeable by all users.
See the 4.9.7.7 SetShellVarContext section in your NSIS documentation. You can use it with $APPDATA to get the application data folder that is writeable for all users.
It's an old issue now but as suggested by Sören APPDATA directory is a nice way to do what you want, the thing is :
Don't take user's personnal APPDATA but the "All Users" APPDATA dir!
This way anyone will be able to access the log file ;-)
Also, I read somewhere that using (BU) on the GrantOnFile is not working well with some systems (Win 7 x64 if I remember well), maybe you should use the SID "(S-1-5-32-545)" instead (it's the All Users' SID, this value is a constant on each Windows OS)
One way: call the shell, and use cacls or xcacls.
Why not create a log-directory in the user's %APPDATA% directory? Do you really need to put all the logs in the install directory? Why?