I set up a SVN and I am using TortoiseSVN as client. I imported my project to the SVN and now I made changes which I want to commit. So I click commit to do that, what I get is:
Access denied to c:\users\username
Why is that? I already searched google, but found nothing? Any ideas? I am running that in Win7 64bit.
Thanks
it is because, your svn server does not allow your user to commit, please goto your server management and put the access for the user, you have to set a rule for the user.
[groups]
gurus = user1, user2
project1 = user1, user2
project2= user1, user2
[/]
* = rw
[project1:/]
* =
#project1 = rw
[project2:/]
* =
#project2 = rw
Set your rulr like this
Related
I have a locally hosted version of bitbucket, and a github account. I want to be able to connect to both easily. I tried this .gitconfig version, does not work seamlessly. What Am I missing? What should I put under user in both systems?
#Github (default)
Host gh
HostName github.com
User ?
IdentityFile ~/.ssh/id.pub
#Bitbucket (secondary)
Host bb
HostName stash.company.com
User ?
IdentityFile ~/.ssh/id.pub
In your local repo, a "remote" is defined to tell git what repository to go to when doing things like push and pull.
The default name is "origin".
So we enter commands like "git pull origin main"
The command "git remote -v" will show the "remotes you have defined, like this:
git remote -v
origin git#github.com:/.git (fetch)
origin git#github.com:/.git (push)
You can define another remote to point to a different remote repo:
git remote add
So if you add a remote and call it bborigin then
git pull bborigin main
would pull the main branch on remote bborigin
(I do not know if you will need special steps to set up authentication on the different remotes)
First, you need to put that in ~/.ssh/config
That means you can:
test your authentication with ssh -Tv gh or ssh -Tv bb
use those Host entries in SSH URLs with
git clone gh:me/myGitHubRepository
git clone bb:me/myBitBucketRepository
Second, a typical global .gitconfig (in $HOME\.gitconfig) would look like:
[alias]
st = status
lg2 = log --graph --format=format:'%C(bold blue)%h%C(reset) - %C(bold cyan)%aD%C(reset) %C(bold green)(%ar)%C(reset)%C(bold yellow)%d%C(reset)%n'' %C(white)%s%C(reset) %C(bold white)- %an%C(reset)' --abbrev-commit
lg = !"git lg2"
br = branch
[user]
name = You
email = your#email.com
[core]
autocrlf = false
safecrlf = false
commitGraph = true
quotepath = false
longpaths = true
[rebase]
autostash = true
autosquash = true
[pull]
rebase = true
[protocol]
version = 2
[gc]
writeCommitGraph = true
[credential "helperselector"]
selected = manager-core
[credential]
helper = manager-core
manager = manager-core
[init]
defaultBranch = main
This assumes you have downloaded and installed GCM (Git Credential Manager), the credential manager which helps caching your credentials (username/password) for HTTPS URL.
Not mandatory in your case, though, if you stick to SSH URLs.
Over the past week, our users have been reaching out complaining that they can't upload/modify files on the company file server. Specifically, they'll try dragging files onto the share through Windows Explorer and will be faced with 'Access Denied'.
The fileserver is a Ubuntu VM that's joined to the Windows domain using the following documentation Setting_up_Samba_as_a_Domain_Member. Admittedly I used our old smb.conf(see below) from the old file server, as my understanding of Linux/Samba is very limited and needing to get the share up and running as soon as possible.
Here's what I've done so far
1. SSHd into the file server and checked the permissions of a folder that was known to be having issues.
ls -ll directory_in_question
drwxrwsr-x 12 root name_of_active_directory_group 4096 Dec 17 15:21 ./
Noticed that 'name_of_active_directory_group' seems to be correct, however the members of this group still can't upload files to this location through Explorer.
2. Checked to see if I can even access the group using getent group 'name_of_active_directory_group, and I'm given name_of_active_directory_group:*:10083:username_one,username_two..., I even try running id username_one and It seems to be reaching our AD DC fine.
3. Set the logging level of Samba to 5 and monitor for anything useful in /var/log/samba/. The only line that really jumps out to me is smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_ACCESS_DENIED]. However I can always provide the full log if it helps.
Temporary Fix
If I run setfacl -Rm u:username:rwX directory_in_question then the user will be able to make changes. Or if I change the permissions of the folder to chmod o+rwx directory_in_question then It works without a hitch. However, chmod g+rwx directory_in_question where I'm specifying the group directly with chmod doesn't work.
The smb.conf looks like this
#======================= Global Settings =======================
[global]
## Browsing/Identification ###
server string = %h server (Samba, Ubuntu)
security = ads
workgroup = COMPANY_A
realm = COMPANY_A.net
# dedicated keytab file = /etc/krb5.keytab
kerberos method = system keytab
disable netbios = Yes
load printers = No
printing = bsd
printcap name = /dev/null
disable spoolss = Yes
## User mapping!! (to map old users on server)
username map = /etc/samba/smbusers
#### Debugging/Accounting ####
# This tells Samba to use a separate log file for each machine
# that connects
log file = /var/log/samba/log.%m
# log level = 5
# Cap the size of the individual log files (in KiB).
max log size = 1000
# If you want Samba to only log through syslog then set the following
# parameter to 'yes'.
# syslog only = no
# We want Samba to log a minimum amount of information to syslog. Everything
# should go to /var/log/samba/log.{smbd,nmbd} instead. If you want to log
# through syslog you should set the following parameter to something higher.
syslog = 0
# Do something sensible when Samba crashes: mail the admin a backtrace
panic action = /usr/share/samba/panic-action %d
# Log level
# log level = 5
lm announce = no
server max protocol = SMB3
server min protocol = NT1
client max protocol = SMB3
client min protocol = NT1
[share]
comment = Share folder
path = /mnt/share_name
read only = no
guest ok = no
directory mask = 0744
force directory mode = 02775
create mask = 0664
force create mode = 0664
follow symlinks = yes
wide links = no
veto files = /._*/.DS_Store/
vfs objects = streams_xattr
Realm List Info
realm list info
company_A.net
type: kerberos
realm-name: company_A.NET
domain-name: company_A.net
configured: kerberos-member
server-software: active-directory
client-software: winbind
required-package: winbind
required-package: libpam-winbind
required-package: samba-common-bin
login-formats: COMPAND_A\%U
login-policy: allow-any-login
company_A.net
type: kerberos
realm-name: company_A.NET
domain-name: company_A.net
configured: kerberos-member
server-software: active-directory
client-software: sssd
required-package: sssd-tools
required-package: sssd
required-package: libnss-sss
required-package: libpam-sss
required-package: adcli
required-package: samba-common-bin
login-formats: %U
login-policy: allow-permitted-logins
permitted-logins:
permitted-groups:
Go and read the Samba wiki page again and then setup your smb.conf correctly, this time without sssd.
I also noticed this '## User mapping!! (to map old users on server)' , that isn't what the usermap is for (well, not in an AD domain).
I have setup an SVN server on RHEL 7.2 machine with in-built RPM. After I have created a repository.
After the creation of the repository demorepo, I was successful in accessing the repository in one client through 'svn+ssh' protocol using 'root' user.
But later I enabled path-based authorization and configured the svnserve.conf, passwd and authz files of the repository as below:
svnserve.conf file
anon-access = none
auth-access = write
password-db = passwd
authz-db = authz
passwd file
rouser1 = pswd1
rouser2 = pswd2
rwuser1 = pswd3
rwuser2 = pswd4
spluser = pswd5
authz file
[groups]
readgrp = rouser1,rouser2,spluser
writegrp = rwuser1,rwuser2
[demorepo:/]
#readgrp = r
#writegrp = rw
[demorepo:/proj1]
spluser = rw
[demorepo:/proj2]
spluser =
Now, after the configuration of the above files, I am successful in accessing the repository through the "svn" protocol (not through the ssh tunnel) but I lost the access through the "svn+ssh" protocol.
So, is there any way to access the repository with the both the protocols simultaneously while path-based authorization is enabled? Or please let me know if I had done any mistake in my configuration?
mostly it is path issue .
if you are using same path for svn and 'svn+ssh' then that the issue as ssh will take full path so if we assume /proj1 is located in
/home/user/project1
the svn+ssh path will be yoursite.com/home/user/project1
while the svn path is yoursite.com/project1
Ok, so I'm trying to configure and install svnserve on my Ubuntu server. So far so good, up to the point where I try to configure sasl (to prevent plain-text passwords).
So; I installed svnserve and made it run as a daemon (also installed it as a startup script with the command svnserve -d -r /var/svn).
My repository is in /var/svn and has following configuration (to be found in /var/svn/myrepo/conf/svnserve.conf) (I left comments out):
[general]
anon-access = none
auth-access = write
realm = my_repo
[sasl]
use-sasl = true
min-encryption = 128
max-encryption = 256
Over to sasl, I created a svn.conf file in /usr/lib/sasl2/:
pwcheck_method: auxprop
auxprop_plugin: sasldb
sasldb_path: /etc/my_sasldb
mech_list: DIGEST-MD5
I created it in that folder as the article at this link suggested: http://svnbook.red-bean.com/nightly/en/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sasl (and also because it existed and was listed as a result when I executed locate sasl).
Right after that I executed this command:
saslpasswd2 -c -f /etc/my_sasldb -u my_repo USERNAME
Which also asked me for a password twice, which I supplied. All going great.
When issuing the following command:
sasldblistusers2 -f /etc/my_sasldb
I get the - correct, as far as I can see - result:
USERNAME#my_repo: userPassword
Restarted svnserve, also restarted the whole server, and tried to connect.
This was the result from my TortoiseSVN client:
Authentication error from server: SASL(-13): user not found: unable to canonify
user and get auxprops
I have no clue at all in what I'm doing wrong. I've been scouring the web for the past few hours, but haven't found anything but that I might need to move the svn.conf file to another location - for example, the install location of subversion itself. which svn results in /usr/bin/svn, thus I moved the svn.conf to /usr/bin (although that doesn't feel right to me).
Still doesn't work, even after a new reboot.
I'm running out of ideas. Anyone else?
EDIT
I tried changing this (according to what some other forums on the internet told me to do): in the file /etc/default/saslauthd, I changed
START=no
MECHANISMS="pam"
to
START=yes
MECHANISMS="sasldb"
(Actually I had already changed START=no to START=yes before, but I forgot to mention it). But still no luck (I did reboot the whole server).
It looks like svnserve uses default values for SASL...
Check /etc/sasl2/svn.conf to be readable by the svnserver process owner.
If /etc/sasl2/svn.conf is owned by user root, group root and --rw------, svnserve uses the default values.
You will not be warned by any log file entry..
see section 4 of https://svn.apache.org/repos/asf/subversion/trunk/notes/sasl.txt:
This file must be named svn.conf, and must be readable by the svnserve process.
(it took me more than 3 days to understand both svnserve-sasl-ldap and this pitfall at the same time..)
I recommend to install the package cyrus-sasl2-doc and to read the section Cyrus SASL for System Administrators carefully.
I expect this is caused by the SASL API for the call
result = sasl_server_new(SVN_RA_SVN_SASL_NAME,
hostname, b->realm,
localaddrport, remoteaddrport,
NULL, SASL_SUCCESS_DATA,
&sasl_ctx);
if (result != SASL_OK)
{
svn_error_t *err = svn_error_create(SVN_ERR_RA_NOT_AUTHORIZED, NULL,
sasl_errstring(result, NULL, NULL));
SVN_ERR(write_failure(conn, pool, &err));
return svn_ra_svn__flush(conn, pool);
}
as you may see, handling the access failure by svnserve is not foreseen, only Ok or error is expected...
I looked in /var/log/messages and found
localhost svnserve: unable to open Berkeley db /etc/sasldb2: No such file or directory
When I created the sasldb to the above file and got the permissions right, it worked. Looks like it ignores or does not use the sasl database path.
There was another suggestion that rebooting solved the problem but that option was not available to me.
I have a copy of a repo on my localhost with a saved username / password for the SVN repo.
The problem is that I changed my svn password (and would like to keep it that way) but every time I try to svn commit, it is asking for my GNOME keyring password (which I enter correctly). This is odd in the first place because I never had it ask me this before.
Then, after entering my password to the keyring, I get this error message:
svn: OPTIONS of 'PATH_TO_CHANGED_FILES': authorization failed: Could not authenticate to server: rejected Basic challenge (REPO_URL)
This is happening on 2 repos that I have but a 3rd one is just fine.
When I disable authentication on the server, everything commits just fine and if I try to update / commit from another server, it also works just fine.
I tried adding the following lines to my ~/.subversion/servers:
store-passwords = no
store-plaintext-passwords = no
And I also tried adding the following lines to my ~/.subversion/config:
store-passwords = no
store-auth-creds = no
But those config file changes do nothing.
Is there a way for my localhost svn to forget the username and passwords I have entered for these repos (they were saved before) so I can get back to everything?
I was able to solve this by deleting the keyring file for MATE. It is a bit of a brute way of doing it but it worked. You can delete the keyring file for MATE with the following command:
rm ~/.config/mate/keyrings/*.keyring
I don't know, how to remove stored data from keyring (old pass for repo), but you can try to replace it.
Use in console any SVN command, which will require authentication with additional options
Global options:
--username ARG : specify a username ARG
--password ARG : specify a password ARG
and test repo-communication in usual way after it
About keyring pass-request:
Check settings in ~/.subversion/config, [auth] section for password-stores =
Check settings in ~/.subversion/servers, [global] section for
store-passwords =
store-plaintext-passwords =