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 last year.
Improve this question
I have been trying to enable logging in my OpenLDAP setup (in Oracle Enterprise Linux 6.5) , but no logs are being generated in /var/log/slapd/slapd.log.
Followed these steps to enable logging :
Edited the slapd.conf file :
# grep -i loglevel /etc/openldap/slapd.conf
loglevel -1
Did the setup for the log directory in /var/log/slapd
# cd /var/log/slapd ; ls -ltr
-rw------- 1 root root 217 May 21 19:48 slapd.log
Edited the rsyslog config file
# grep -i local4 /etc/rsyslog.conf
local4. /var/log/slapd/slapd.log*
restarted the openldap service and also the rsyslogger :
# service rsyslog restart
# service slapd restart
But even after doing these steps , we are not seeing logs captured in the slapd.log file . Only log seen is the below line :
more /var/log/slapd/slapd.log
May 21 19:48:12 sprdneval slapd[2961]: #(#) $OpenLDAP: slapd 2.4.39 (Aug 16 2014 20:41:55) $#012#011mockbuild#ca-buildj3.us
.oracle.com:/builddir/build/BUILD/openldap-2.4.39/openldap-2.4.39/build-servers/servers/slapd
Am i missing to do something blindingly obvious ?
Regards,
Hari
If you are using the OnLine Configuration (OLC) have a look at Zytrax. It explains quite well how to use and configure it.
Same problem here ('loglevel any' and 'logfile /var/log/slapd/slapd.log' options in slapd.conf and in the cn=config, but no debug output in the logfile).
I've just solved the problem by adding "-d any" to the command line arguments of the slapd
/usr/bin/slapd -d any -u ldap -g ldap -h "ldap://127.0.0.1/ ldaps:/// ldapi:///"
I see the same issue and posted my question at Serverfault about what '-s' option means.
If you see olcLogLevel setting at current config:
$ sudo grep olcLogLevel /etc/openldap/slapd.d/cn=config.ldif
olcLogLevel: 0
Then, you can change it by:
$ sudo ldapmodify -Y EXTERNAL -H ldapi:/// <<EOF
dn: cn=config
changetype: modify
replace: olcLogLevel
olcLogLevel: 256
EOF
If you don't see olcLogLevel setting, then you need to newly create the entry. I haven't seen the case but I think it will be done by change 'changetype' above from 'modify' to 'add'.
My environment is CentOS7.9 so that the path would be different from yours.
You can do and check df -h to check disk space and delete heavy files which you do not require (like messages*.gz) from /var/log/ also empty the content of /var/log/slapd/slapd.log
Now you reboot your system and check service slapd status.
Hope ,it works now.
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 2 years ago.
Improve this question
I am working on a raspberry pi and am having a tough time giving permissions to an external hard drive that I have mounted using the following tutorial:
http://www.howtogeek.com/139433/how-to-turn-a-raspberry-pi-into-a-low-power-network-storage-device/
I have now created folders on that external hard drive and when I do a ls -l command I get the following returned:
drwxr-xr-x 2 root root 512 Aug 28 23:24 test
That is located in: /media/USBHDD1/shares
Now I'm trying to give it all write read and execute permissions or even change the owner and group to pi:pi
However, chmod 777 is not working – it doesn't return an error, just seems to have no effect
And when I use
sudo chown -R pi:pi test/
I get the error
chown: changing ownership of `test/': Operation not permitted
This is a linux question but I think someone with background and knowledge of using a raspberry pi can help me out here.
Extra info as requested:
When I run pi#raspberrypi /media $ grep USBHDD1 /etc/mtab
it returns:
/dev/sda1 /media/USBHDD1 vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro 0 0
The reason is because the ownership and permissions are defined at mount time for the vfat FS.
Manual page mount(8):
Mount options for fat ..
uid=value and gid=value
Set the owner and group of all files. (Default: the uid and gid
of the current process.)
umask=value
Set the umask (the bitmask of the permissions that are not
present). The default is the umask of the current process. The
value is given in octal.
There are at least three things you can do:
(1) Give pi:pi access to the entire /media/USBHDD1 mount:
mount -o remount,gid=<pi's gid>,uid=<pi's uid> /media/USBHDD1
To determine pi's uid:
cat /etc/passwd |grep pi
To determine pi's gid:
cat /etc/group |grep pi
(2) Give everyone access to /media/USBHDD1 by changing the umask and dmask (not recommended):
mount -o remount,umask=000,dmask=000 /media/USBHDD1
(3) Change the partition to a different file system. Only do this if you're not accessing the the external hard drive from a windows computer:
You won't be able to convert the file system from VFAT to a Unix-compatible FS, so you'll have to backup the contents of the drive, format as EXT3+ or reiserfs, then copy the contents back. You can find tutorials for doing this on the web.
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.
The community reviewed whether to reopen this question 12 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I have 2 linux machines. On one machine these are the users:
sysadmin2:x:4201:4200::/home/sysadmin2:/bin/bash
appadmin1:x:4100:4100::/home/appadmin1:/bin/bash
appadmin2:x:4101:4100::/home/appadmin2:/bin/bash
dataadmin1:x:4300:4300::/home/dataadmin1:/bin/bash
dataadmin2:x:4301:4300::/home/dataadmin2:/bin/bash
sysadmin1:x:4200:4200::/home/sysadmin1:/bin/bash
I want to replicate these to another machine. How can I create these users with same uid and gid values? Is there a way I can copy them to another machine?
First, create the group if it doesn't exist:
$ groupadd -g 4200 sysadmin2
Next, create the user and add it to the group:
$ useradd sysadmin2 -u 4201 -g 4200 -m -s /bin/bash
$ useradd appadmin1 -u 4100 -g 4100 -m -s /bin/bash
and don't forget to reset password for each user.
In summary and in general, you can use the useradd command to add users to a linux system. The -u flag allows you to set a specific user id and the -g flag allows you to set a specific group id. Please see useradd's manpage for more details -- on a terminal, type man useradd to see it.
Now, specifically about your problem, see below.
Assumming you have three groups on your original machine:
$ cat /etc/group
...
appadmins:x:4100:
sysadmins:x:4200:
dataadmins:x:4300:
...
On your destination/new machine, you should first create the groups using:
groupadd appadmins -g4100
groupadd sysadmins -g4200
groupadd dataadmins -g4300
Then, you can proceed to create the actual users like so:
useradd appadmin1 -u4100 -g4100 -d/home/appadmin1 -s/bin/bash
useradd appadmin2 -u4101 -g4100 -d/home/appadmin1 -s/bin/bash
useradd sysadmin1 -u4200 -g4200 -d/home/sysadmin1 -s/bin/bash
useradd sysadmin2 -u4201 -g4200 -d/home/sysadmin2 -s/bin/bash
useradd dataadmin1 -u4300 -g4300 -d/home/dataadmin1 -s/bin/bash
useradd dataadmin2 -u4301 -g4300 -d/home/dataadmin2 -s/bin/bash
The -d option is used to set the home directory and the -s option is used to set the shell. Again, -u and -g are used to set a specific user and group id.
To check that everything went correctly, just use grep admin on your /etc/passwd file:
$ grep admin /etc/passwd
appadmin1:x:4100:4100::/home/appadmin1:/bin/bash
appadmin2:x:4101:4100::/home/appadmin1:/bin/bash
sysadmin1:x:4200:4200::/home/sysadmin1:/bin/bash
sysadmin2:x:4201:4200::/home/sysadmin2:/bin/bash
dataadmin1:x:4300:4300::/home/dataadmin1:/bin/bash
dataadmin2:x:4301:4300::/home/dataadmin2:/bin/bash
If something is wrong, you can use userdel or groupdel accordingly and start over.
The account configure files could be shared by any Linux machine in same privileges. you could make a copy to that machine to have a same user list by this command:
scp /etc/{passwd,shadow} root#your_marchine_IP_address:/etc/ -p
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 9 years ago.
Improve this question
Apache
CentosOS 5
Plesk 10
New on commandline and ssh.
While trying to get several users (root git friend) to ssh to the same shell and configuring passwordless connection I must have made a mistake.
I can no longer login over ssh as root or git but can as friend whose shell I transferred by editting etc/passwd.
I luckily can still login on plesk so gui file editing is possible.
here's what I found in my sshd errorlog
sshd[11999]: User git not allowed because shell /bin/bash\r does not exist
sshd[12000]: input_userauth_request: invalid user git
sshd[11999]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=xxx.xxx.xxx.dynamic.upc.nl user=git
sshd[11999]: Failed password for invalid user git from xxx.xxx.xxx port 54851 ssh2
I read something about sudo ing and incidently entering: causing the \r
But where to restore?
Here are some configurations
etc/ssh/sshd_config :
PubkeyAuthentication yes
ect/shells
/bin/sh
/bin/bash
/sbin/nologin
/bin/tcsh
/bin/csh
/bin/false
/usr/local/psa/bin/chrootsh
/bin/rbash
etc/passwd
git:x:10009:10009::/home/git:/bin/bash
friend:x:10010:10010::/home/git:/bin/bash
earlier I tried to install password less connecting
so there is a .ssh/id_rsa file somewhere on the server and on my local machine.
After reading Git's famous "ERROR: Permission to .git denied to user"
I tried
ssh-add -l
Could not open a connection to your authentication agent
My problem resembles this:
https://serverfault.com/questions/480806/ssh-root-access-denied-after-changing-shell
If I am logged over ssh as friend I cannot sudo to root:
sudo root
friend is not in the sudoers file
nor can I chsh
[friend#vpsXXX ~]$ chsh -s /bin/bash root
chsh: Running UID doesn't match UID of user we're altering, shell change denied
Hope someone can clear this up for me.
Happy to supply more info if needed
/bin/bash\r
means that you've edited the /etc/passwd or /etc/shells with a Windows editor as it contains Windows line feeds \r\n. Linux interprets only the \n and assumes that the remaining \r is part of the binary name.
Solution: Open the files in a Linux editor and remove the new line and add it again.
Also you could install the package tofrodos and execute:
fromdos /etc/passwd
fromdos /etc/shells
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/