chmod cannot change group permission on Cygwin - cygwin

I am using Cygwin and trying to change the group access permission with chmod, e.g.
$ls -l id_rsa
-rwxrwxr-- 1 None 1679 Jun 13 10:16 id_rsa
$ chmod g= id_rsa
$ ls -l id_rsa
-rwxrwxr-- 1 None 1679 Jun 13 10:16 id_rsa
But this does not work. I can change permission for user and others. Seems that the permission level for group somehow keeps the same as that of user?

I was having a similar problem to you, and I was using the NTFS filesystem, so Keith Thompson's answer didn't solve it for me.
I changed the file's group owner to the Users group:
chown :Users filename
After doing that I was able to change the group permissions to my will using chmod. In my case, since it was an RSA key for OpenSSH, I did:
chmod 700 filename
And it worked. In Cygwin you get two groups by default, the Root group and the Users group. I wanted to add another group, but I wasn't able to do it with the tools I'm used to use on Linux. For that reason I just used the Users group.

Cygwin doesn't like files to be owned by groups that it doesn't know.
Unfortunately, that happens quite often in Cygwin, especially if your PC is in a Windows domain where things keep changing.
I also synchronise my files between two PCs, via an external drive, and the uids/gids are different between the different PCs, so this is a source of problems.
If you do ls -l and see a numeric group id instead of a group name, it means Cygwin doesn't know the gid - i.e. it's not in /etc/group, and Cygwin can't query it from Windows either. You can confirm this by running getent group <gid>, where <gid> is the numeric group id.
To fix it, you can either use chgrp to change the group for all affected files/directories, as described in the accepted answer above, or create an entry for the unknown gid in /etc/group, with any unused group name (e.g. Users2).
After doing this, it may be necessary to close all of your Cygwin windows and then re-open them.

An experiment shows that chmod does work correctly to change group permissions under Cygwin.
The experiment used a file on an NTFS partition. Cygwin implements a POSIX layer on top of Windows, but it still ultimately uses the features of Windows itself, and of the particular filesystem implementation.
On modern versions of Windows, most hard drives are formatted to use NTFS, which provides enough support for chmod. But external USB drives typically use FAT32, which doesn't have the same abilities to represent permissions. The Cygwin layer fakes POSIX semantics as well as it can, but there's only so much it can do.
Try
$ df -T .
If it indicates that you're using a FAT32 filesystem, that's probably the problem. The solution would be to store the file on an NTFS filesystem instead. A file named id_dsa is probably an SSH private key, and it needs to be stored in $HOME/.ssh anyway.
Is your home directory on a FAT32 partition? As I recall, recent versions of Windows ("recent" meaning the last 10 or more years) are able to convert FAT32 filesystems to NTFS.
The remainder of this answer was in response to the original version of the question, which had a typo in the chmod command.
Cygwin uses the GNU Coreutils version of chmod. This,
chmod g=0 fileName
is not the correct syntax. I get:
$ chmod g=0 fileName
chmod: invalid mode: `g=0'
Try `chmod --help' for more information.
(This is on Linux, not Cygwin, but it should be the same.)
To turn off all group permissions, this should work:
$ chmod g= fileName
$ ls -l fileName
-rw----r-- 1 kst kst 0 Jun 13 10:31 fileName
To see the chmod documentation:
$ info coreutils chmod
To see the documentation on symbolic file mode:
$ info coreutils Symbolic
The format of symbolic modes is:
[ugoa...][+-=]PERMS...[,...]
where PERMS is either zero or more letters from the set 'rwxXst', or a
single letter from the set 'ugo'.

Like previous answers, not recognized groups cause such issues. It mostly happens in Windows Domains.
The easiest way to fix it is regenerate your /etc/passwd and /etc/group files (parameter -d is needed for domain users):
mkpasswd -l -d > /etc/passwd
mkgroup -l -d > /etc/group
Close and launch Cygwin again.

This is a very annoying issue for me. In my case user135348's solution worked best. The biggest issue with the chown :Users -R approach is that every time a new file is created, it will be assigned to the unknown gid 1049120. It's very frustrating to keep changing file gid.
I tried mkgroup too, but in my case it didn't work: My gid is 1049120.
Based on the rules explained in Mapping Windows SIDs to POSIX uid/gid values : : 0x100000 offset is used for account from the machine's primary domain.
Trying to remove the same offset from 1049120, you get 544, which is built-in Administrators group's RID.
This account is not a member of the local Administrators group; we use SuRun to grant administrator rights without giving out credentials. In this case, mkgroup failed to generate all the possible gids.
Editing the group file and adding a customized group name seems always to fix the issue easily.

I had this issue when working remotely from the Domain and using cygserver.
Running ls -l showed a numeric group id instead of a group name.
I stopped cygserver, net stop "CYGWIN cygserver, and other Cygwin processes, then ran the ls -l again, and group names were then displayed correctly.
I guess cygserver was holding incomplete domain group information.
After restarting cygserver the system continued to work correctly.

#!/bin/bash
find . |while read obj; do
if [[ -d "$obj" ]]; then
setfacl --set "user::rwx,group::r-x,other::r-x" "${obj}"
elif [[ -f "$obj" ]]; then
setfacl --set "user::rw-,group::r--,other::r--" "${obj}"
fi
done

You must specify the group name on the Windows system which your user belongs to.
So I just did this:
chown -R ONEX:Users ~/*
You can find your user name and group here:

Related

zsh compinit: insecure directories. Compaudit shows /tmp directory

I'm running zsh on a Raspberry Pi 2 (Raspbian Jessie). zsh compinit is complaining about the /tmp directory being insecure. So, I checked the permissions on the directory:
$ compaudit
There are insecure directories:
/tmp
$ ls -ld /tmp
drwxrwxrwt 13 root root 16384 Apr 10 11:17 /tmp
Apparently anyone can do anything in the /tmp directory. Which makes sense, given it's purpose. So I tried the suggestions on this stackoverflow question. I also tried similar suggestions on other sites. Specifiacally, it suggests turning off group write permissions on that directory. Because of how the permissions looked according to ls -ld, I had to turn off the 'all' write permissions as well. So:
$ sudo su
% chmod g-w /tmp
% chmod a-w /tmp
% exit
$ compaudit
# nothing shows up, zsh is happy
This shut zsh up. However, other programs started to break. For example, gnome-terminal would crash whenever I typed the letter 'l'. Because of this, I had to turn the write permissions back on, and just run compinit -u in my .zshrc.
What I want to know: is there any better way to fix this? I'm not sure that it's a great idea to let compinit use an insecure directory. My dotfiles repo is hosted here, and the file where I now run compinit -u is here.
First, the original permissions on /tmp were correct. Make sure you've restored them correctly: ls -ld /tmp must start with drwxrwxrwt. You can use sudo chmod 1777 /tmp to set the correct permissions. /tmp is supposed to be writable by everyone, and any other permissions is highly likely to break stuff.
compaudit complains about directories in fpath, so one of the directories in your fpath is of the form /tmp/… (not necessarily /tmp itself). Check how fpath is being set. Normally the directories in fpath should be only subdirectories of the zsh installation directory, and places in your home directory. A subdirectory of /tmp wouldn't get in there without something unusual on your part.
If you can't find out where the stray directory is added to fpath, run zsh -x 2>zsh-x.log, and look for fpath in the trace file zsh-x.log.
It can be safe to use a directory under /tmp, but only if you created it securely. The permissions on /tmp allow anybody to create files, but users can only remove or rename their own files (that's what the t at the end of the permissions means). So if a directory is created safely (e.g. with mktemp -d), it's safe to use it in fpath. compaudit isn't sophisticated enough to recognize this case, and in any case it wouldn't have enough information since whether the directory is safe depends on how it was created.

Does Cygwin lock out chmod changes for system user?

Similar to this question, I am unable to unset execute permissions on files after recently upgrading Cygwin.
I have a file with the following permissions:
ls -l filename
-rw-rwxr--+ 1 gstrycker Users 1334935 Jan 26 09:23 filename
I'm trying to get rid of execute privileges, but running chmod -x or even chmod 0 does not seem to work now (note that it always did work for me before -- but I don't believe there were this many columns in the POSIX security permissions)
chmod 0 filename
ls -l filename
----rwx---+ 1 gstrycker Users 1334935 Jan 26 09:23 filename
Why can I not seem to be able to modify this central group of privileges now? I've always been able to before. I even tried to change the group owner, but that didn't seem to help.
I'm stuck -- any ideas? Is this a new Cygwin bug? Did Cygwin recently add columns to the POSIX permissions, and if so, how do I access these?

Symlink giving "Permission denied"... to root

I wrote a simple script to automate creating a symbolic link.
#!/pseudo
today = "/tmp/" + date("Y-m-d")
exec("ln -sf " + today + " /tmp/today")
Simple enough; get today's date and make a symlink. Ideally run after midnight with -f so it just updates it in-place.
This works just fine! ...for my user.
xkeeper /tmp$ ls -ltr
drwxrwxrwx xkeeper xkeeper 2014-10-21
lrwxrwxrwx xkeeper xkeeper today -> /tmp/2014-10-21/
xkeeper /tmp$ cd today
xkeeper /tmp/today$ cd ..
Notice that it works fine, all the permissions are world-readable, everything looks good.
But if someone else wants to use this link (we'll say, root, but any other user has this problem), something very strange happens:
root /tmp# cd today
bash: cd: today: Permission denied
I am at a complete loss as to why this is. I've also tried creating the links with ln -s -n -f (not that "--no-dereferencing" is very well-explained), but the same issue appears.
Since /tmp usually has the sticky bit set, the access to /tmp/today is denied because of protected_symlinks.
You can disable this protection by setting
sysctl -w fs.protected_symlinks=0
protected_symlinks:
A long-standing class of security issues is the symlink-based
time-of-check-time-of-use race, most commonly seen in world-writable
directories like /tmp. The common method of exploitation of this flaw
is to cross privilege boundaries when following a given symlink (i.e. a
root process follows a symlink belonging to another user). For a likely
incomplete list of hundreds of examples across the years, please see:
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=/tmp
When set to "0", symlink following behavior is unrestricted.
When set to "1" symlinks are permitted to be followed only when outside
a sticky world-writable directory, or when the uid of the symlink and
follower match, or when the directory owner matches the symlink's owner.
This protection is based on the restrictions in Openwall and grsecurity.
For further details check this.

Copy files from one user home directory to another user home directory in Linux

I have the logins and passwords for two linux users (not root), for example user1 and user2.
How to copy files
from /home/user1/folder1 to /home/user2/folder2, using one single shell script (one single script launching, without manually switching of users).
I think I must use a sudo command but didn't found how exactly.
Just this:
cp -r /home/user1/folder1/ /home/user2/folder2
If you add -p (so cp -pr) it will preserve the attributes of the files (mode, ownership, timestamps).
-r is required to copy hidden files as well. See How to copy with cp to include hidden files and hidden directories and their contents? for further reference.
sudo cp -a /home/user1/folder1 /home/user2/folder2
sudo chown -R user2:user2 /home/user2/folder2
cp -a archive
chown -R act recursively
Copies the files and then gives permissions to user2 to be able to access them.
Copies all files including dot files, all sub-directories and does not require directory /home/user2/folder2 to exist prior to the command.
(shopt -s dotglob; cp -a /home/user1/folder1/* /home/user2/folder2/)
Will copy all files (including those starting with a dot) using the standard cp. The /folder2/ should exist, otherwise the results can be nasty.
Often using a packing tool like tar can be of help as well:
cd /home/user1/folder1
tar cf - . | (cd /home/user2/folder2; tar xf -)
I think you need to use this command
sudo -u username /path1/file1 /path2/file2
This command allows you to copy the contents as a particular user from any file path.
PS: The parent directory should be list-able at least in order to copy files from it.
Just to add to fedorqui 'SO stop harming' answer.
I had this same challenge when I tried to change the default admin user for a server from stage_user to prod_user on an Ubuntu 20.04 machine:
First, I created a prod_user using the command below:
sudo adduser prod_user
And then I added the newly created prod_user to the sudo group:
sudo adduser prod_user sudo
Next, I copied all the directories that I needed from the home directory of the stage_user to the prod_user:
sudo cp -r /home/stage_user/folder1/ /home/prod_user/
Next, I changed the ownership of the copied folders from stage_user to prod_user to avoid permission issues:
sudo chown prod_user:prod_user /home/prod_user/folder1
That's all.
I hope this helps
The question has to to do with permissions across users.
I believe by default home permission does allow all people to do listing and changing working directory into another's home:
eg. drwxr-xr-x
Hence in the previous answers people did not realise what you might have encountered.
With more restricted settings like what I had on my web host, nonowner users cannot do anything
eg. drwx------
Even if you use su/sudo and become the other user, you can still only be ONE USER at one time, so when you copy the file back, the same problem of no enough permission still apply.
So. . . use scp instead, treat the whole thing like a network environment let me put it that way and that's it. By the way this question had already been answered once over here (https://superuser.com/questions/353565/how-do-i-copy-a-file-folder-from-another-users-home-directory-in-linux), only cared to reply because this ranked 1st result from my search.

rsync - mkstemp failed: Permission denied (13) [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 1 year ago.
Improve this question
I have the following setup to periodically rsync files from server A to server B. Server B has the rsync daemon running with the following configuration:
read only = false
use chroot = false
max connections = 4
syslog facility = local5
log file = /var/adm/rsyncd.log
munge symlinks = false
secrets file = /etc/rsyncd.secrets
numeric ids = false
transfer logging = true
log format = %h %o %f %l %b
[BACKUP]
path = /path/to/archive
auth users = someuser
From server A I am issuing the following command:
rsync -adzPvO --delete --password-file=/path/to/pwd/file/pwd.dat /dir/to/be/backedup/ someuser#192.168.100.100::BACKUP
BACKUP directory is fully read/write/execute to everyone. When I run the rsync command from server A, I see:
afile.txt
989 100% 2.60kB/s 0:00:00 (xfer#78, to-check=0/79)
for each and everyfile in the directory I wish to backup. It fails when I get to writing tmp files:
rsync: mkstemp "/.afile.txt.PZQvTe" (in BACKUP) failed: Permission denied (13)
Hours of googling later and I still can't resolve what seems to be a very simple permission issue. Advice? Thanks in advance.
Additional Information
I just noticed the following occurs at the beginning of the process:
rsync: failed to set permissions on "/." (in BACKUP): Permission denied (13)
Is it trying to set permission on "/"?
Edit
I am logged in as the user - someuser. My destination directory has full read/write/execute permission for everyone, including it's contents. In addition, the destination directory is owned by someuser and in someuser's group.
Follow up
I've found using SSH solves this
Make sure the user you're rsync'd into on the remote machine has write access to the contents of the folder AND the folder itself, as rsync tried to update the modification time on the folder itself.
Even though you got this working, I recently had a similar encounter and no SO or Google searching was of any help as they all dealt with basic permission issues wheres the solution below is somewhat of an off setting that you wouldn't even think to check in most situations.
One thing to check for with permission denied that I recently found having issues with rsync myself where permissions were exactly the same on both servers including the owner and group but rsync transfers worked one way on one server but not the other way.
It turned out the server with problems that I was getting permission denied from had SELinux enabled which in turn overrides POSIX permissions on files/folders. So even though the folder in question could have been 777 with root running, the command SELinux was enabled and would in turn overwrite those permissions which produced a "permission denied"-error from rsync.
You can run the command getenforce to see if SELinux is enabled on the machine.
In my situation I ended up just disabling SELINUX completely because it wasn't needed and already disabled on the server that was working fine and just caused problems being enabled. To disable, open /etc/selinux/config and set SELINUX=disabled. To temporarily disable you can run the command setenforce 0 which will set SELinux into a permissive state rather then enforcing state which causes it to print warnings instead of enforcing.
Rsync daemon by default uses nobody/nogroup for all modules if it is running under root user. So you either need to define params uid and gid to the user you want, or set them to root/root.
I encountered the same problem and solved it by chown the user of the destination folder. The current user does not have the permission to read, write and execute the destination folder files. Try adding the permission by chmod a+rwx <folder/file name>.
This might not suit everyone since it does not preserve the original file permissions but in my case it was not important and it solved the problem for me. rsync has an option --chmod:
--chmod This option tells rsync to apply one or more comma-separated lqchmodrq strings to the permission of the files in the transfer. The
resulting value is treated as though it was the permissions that the
sending side supplied for the file, which means that this option can
seem to have no effect on existing files if --perms is not enabled.
This forces the permissions to be what you want on all files/directories. For example:
rsync -av --chmod=Du+rwx SRC DST
would add Read, Write and Execute for the user to all transferred directories.
I had a similar issue, but in my case it was because storage has only SFTP, without ssh or rsync daemons on it. I could not change anything, bcs this server was provided by my customer.
rsync could not change the date and time for the file, some other utilites (like csync) showed me other errors: "Unable to create temporary file Clock skew detected".
If you have access to the storage-server - just install openssh-server or launch rsync as a daemon here.
In my case - I could not do this and solution was: lftp.
lftp's usage for syncronization is below:
lftp -c "open -u login,password sftp://sft.domain.tld/; mirror -c --verbose=9 -e -R -L /srs/folder /rem/folder"
/src/folder - is the folder on my PC, /rem/folder - is sftp://sft.domain.tld/rem/folder.
you may find mans by the link lftp.yar.ru/lftp-man.html
Windows: Check permissions of destination folders. Take ownership if you must to give rights to the account running the rsync service.
I had the same issue in case of CentOS 7. I went through lot of articles ,forums but couldnt find out the solution.
The problem was with SElinux. Disabling SElinux at the server end worked.
Check SELinux status at the server end (from where you are pulling data using rysnc)
Commands to check SELinux status and disable it
$getenforce
Enforcing ## this means SElinux is enabled
$setenforce 0
$getenforce
Permissive
Now try running rsync command at the client end ,it worked for me.
All the best!
I have Centos 7 server with rsyncd on board:
/etc/rsyncd.conf
[files]
path = /files
By default selinux blocks access for rsyncd to /files folder
# this sets needed context to my /files folder
sudo semanage fcontext -a -t rsync_data_t '/files(/.*)?'
sudo restorecon -Rv '/files'
# sets needed booleans
sudo setsebool -P rsync_client 1
Disabling selinux is an easy but not a good solution
I had the same issue, so I first SSH into the server to confirm that I able to log in to the server by using the command:
ssh -i /Users/Desktop/mypemfile.pem user#ec2.compute-1.amazonaws.com
Then in New Terminal
I copied a small file to the server by using SCP, to make sure I am able to make a connection:
scp -i /Users/Desktop/mypemfile.pem /Users/Desktop/test.file user#ec2.compute-1.amazonaws.com:/home/user/test/
Then In the same new terminal, I tried running rsync:
rsync -avz -e "ssh -i /Users/Desktop/mypemfile.pem" /Users/Desktop/backup/image.img.gz user#ec2.compute-1.amazonaws.com:
If you're on a Raspberry pi or other Unix systems with sudo you need to tell the remote machine where rsync and sudo programs are located.
I put in the full path to be safe.
Here's my example:
rsync --stats -paogtrh --progress --omit-dir-times --delete --rsync-path='/usr/bin/sudo /usr/bin/rsync' /mnt/drive0/ pi#192.168.10.238:/mnt/drive0/
I imagine a common error not currently mentioned above is trying to write to a mount space (e.g., /media/drivename) when the partition isn't mounted. That will produce this error as well.
If it's an encrypted drive set to auto-mount but doesn't, might be an issue of auto-unlocking the encrypted partition before attempting to write to the space where it is supposed to be mounted.
I had the same error while syncing files inside of a Docker container and the destination was a mounted volume (Docker for mac), I run rsync via su-exec <user>. I was able to resolve it by running rsync as root with -og flags (keep owner and group for destination files).
I'm still not sure what caused that issue, the destination permissions were OK (I run chown -R <user> for destination dir before rsync), perhaps somehow related to Docker for Mac slow filesystem.
Take attention on -e ssh and jenkins#localhost: in next example:
rsync -r -e ssh --chown=jenkins:admin --exclude .git --exclude Jenkinsfile --delete ./ jenkins#localhost:/home/admin/web/xxx/public
That helped me
P.S. Today, i realized that when you change (add) jenkins user to some group, permission will apply after slave (agent) restart. And my solution (-e ssh and jenkins#localhost:) need only when you can't restart agent/server.
Yet still another way to get this symptom: I was rsync'ing from a remote machine over ssh to a Linux box with an NTFS-3G (FUSE) filesystem. Originally the filesystem was mounted at boot time and thus owned by root, and I was getting this error message when I did an rsync push from the remote machine. Then, as the user to which the rsync is pushed, I did:
$ sudo umount /shared
$ mount /shared
and the error messages went away.
The group user name for the destination directory and sub directories should be same as per the user.
if the user is 'abc' then the destination directory should be
lrwxrwxrwx 1 abc abc 34 Jul 18 14:05 Destination_directory
command chown abc:abc Destination_directory
Surprisingly nobody have mentioned all powerful SUDO.
Had the same problem and sudo fixed it
run in root access ssh chould solve this problem
or chmod 0777 /dir/to/be/backedup/
or chown username:user /dir/to/be/backedup/

Resources