I recently copied a bunch of data to a new machine but forgot to enforce ACL permissions. I would like to copy the file/folder security permissions to the destination using robocopy. Here is what I have so far
robocopy C:\Users\Dallas\Desktop\source C:\Users\Dallas\Desktop\destination /sec /secfix /xf "."
This copies the users over but NOT the permissions. Any ideas?
Related
Our current instance of Sitecore (8.2) is set up with one main website and multiple sub-websites. Each sub-website has their own set of users/roles and a folder in the media library. Initially every role has full access to every folder and you must deny certain access (write, create, rename, and delete) manually for each folder for each role. For every new folder that is put into the media library, you must then go back to all the current/older roles and update their permissions (denying the write, create, rename, and delete access) manually for each new folder.
We are looking to simplify this solution so each current/older role is denied permissions automatically for each new folder added and each new role is automatically denied permissions to all current/older folders.
How would this be possible?
Try to avoid denying access, it's not a good practice.
In a clean Sitecore install the role "Sitecore Client Authoring" is given modify permissions on all descendants of the media library root folder. If you remove this role from the root folder, all users will be denied access to all sub folders. Now you can add modify permissions (write, create, rename and delete) for each folder, only for those roles who need access to it.
I'm trying to copy an entire folder with his content from a remote server to a new one, the remote server hasn't installed any pannel and new one has cpanel.
When I run the next instruction it looks to copy everything but it only has copied the folder and it's empty. The folder copied has permissions 700 like in remote but in new server the folders permissions are 755, of course the user and group are different.
I'm running this instruction with different options:
rsync -rlDv --no-perms --no-owner --no-group user#000.000.000.000:/home/user/public_html/folder /home/user/public_html/images/
I've used instead -rlDv -av with and without --no-perms --no-owner --no-group
Nothing works.
Any idea, thank you
Well, finally I've just fixed the problem.
The problem was that the files and folders was uploaded but I was seeing it with user own in cpanel and he can't see that files because the group and user was different, I changed in console to root and after change the owner and permissions to the same of the web and erything began to work fine.
is there any possibility to change the permission when a folder in fileadmin is created per ftp and now you cannot copy a file into this folder?
TYPO3 is version 8.7
Greeting
Volker
You will have 3 Options:
Create the folder with a user that is in apache/nginx/php group, respectively dont use the FTP-Root user on creation.
Connect via FTP and fix the permission of the folder.
Connect via SSH and fix the permission in terminal context.
Regards
Ribase
Your problem is not TYPO3 specific. It's an unix problem.
or better: you need to understand rights management on unix systems.
there are three levels: owner, group, everyone
for each level you can define the possible rights (read, write, execute)
in octal notation this matches exact the bits of coding
rwxrwxrwx
||||||+++-- everyone
|||+++----- group
+++-------- owner
Also each file holds an owner and a group.
Folders are a special kind of files which need execution rights to see the content (list of files).
Then there are default bits that are set if a file (or folder) is generated. These bits can be configured with the umask command - or the program you create the file. with TYPO3 you can define it in the install tool.
Maybe your FTP program has similar configuration.
Depending whether your FTP-user and the PHP/Apache-User are identical, share one group or have nothing in common you need to set the bits for each file to grant access each other.
be aware: independent from your BE-user which you use for login in TYPO3 BE, any file action in the BE (or FE) is done with the apache/PHP user, which probably is not your FTP user.
In a shell you have the commands chmod to change the assess bits and chown to change the owner and group of a file. (hint: chgrp will only change the default group assigned to new files)
If you do not have the writing rights for folder and file you can not change any rights of a file. Especially not the right to modify a file (remember: folders are files).
The best option to modify the rights is to use the same user than the file was created (as an owner you have the most rights).
Second best is to be root. Root is allowed to do anything, but therefore you should avoid being root, as you also can destroy anything.
I've just installed Concrete 5 CMS by following the instructions on the website.
The folders application/files/, application/config/, packages/ and
updates/ will need to be writable by the web server process. This can
mean that the folders will need to be "world writable", depending on
your hosting environment. If your server supports running as
suexec/phpsuexec, the files should be owned by your user account, and
set as 755 on all of them. That means that your web server process can
do anything it likes to them, but nothing else can (although everyone
can view them, which is expected.) If this isn't possible, another
good option is to set the apache user (either "apache" or "nobody") as
having full rights to these file. If neither are possible, chmod 777
to files/ and all items within (e.g. chmod -R 777 file/*)
The packages folder has permission 777 and root/tmp folder has permission 755.
I've uploaded a new theme to /packages over FTP. When I try to install the new theme I see the following error:
An unexpected error occurred. fopen(/root/tmp/1419851019.zip) [function.fopen]: failed to open stream:
Permission denied
I have FTP access to the server and access to CPanel. How do I get this working without granting too many permissions which pose a security risk?
My install has the folders application/files, application/config, packages, and updates all set to 755 and it's working just fine.
You get that error because the system is trying to write to /root/tmp, which apparently is the environment configuration for a temp folder when your PHP request is handled.
Try adding the folder application/files/tmp in your file system (within your concrete5 installation). And then make sure that the user can write to that folder that is running PHP in your environment. As explained in the concrete5's own documentation (that you linked originally), it depends on your server which user this is.
Usually in shared hosting environments it's the same as the account you use to login there through SSH or FTP. In these cases, the 755 permissions should be enough if your own user owns the tmp folder you just created.
I have a shared folder in my network where a lot of users access and store their documents. I'm admin of this shared folder and I've denied delete permissions for all other users.
The problem starts when a user creates a new folder and tries to rename it.
Windows says "Access denied"
I'm assuming that this might be because I've denied delete permissions for that user.
(Since Rename=Delete+CreateFolderWithNewName)
Is there any way so that I can keep the delete permissions intact, and allow the user to rename his files/folders?
Or any other workarounds?
I'm using Windows Server 2008 and NTFS file system.
As suggested, you should look into the folder design / your setup.
A kind of Work around, is to give "Delete" and "Delete subfolders and files" rights to "CREATOR OWNER", then the creator of the file or folder is able to rename (and delete) his own files/folders.
Maybe you could Schedule a nightly powershell script (not privided) which takes ownership of all files and folders, to restrict owners from future renaming/deletion of files
If they creating in the shared folder it will inherit the permissions of the shared folder. You would need to break inheritance and allow delete permissions on the sub folder to achieve what you want.
There are two managable solutions if there are alot of folders created in the root.
Write a service/application to do that for you.
Create a series of folders (perhaps person/team based) in the folder, change the permissions on them and tell users to store files in there.