Member Avatar for bzptqj

Hi,

I am new to Unix and SFTP. My requirement is to transfer files to host server using SFTP command. I know that ther is nothing wrong with my script as I used it before successfully. Yesterday when I tried to run the same script I get the error "Couldn't get handle: Permission denied ". I googled a lot for the same in vain. Can anyone help me. My questions are 1). What is this error (what is the reason for this error) 2). How to resolve this.

Below is the error that I get

Connecting to 10.135.10.55...
Couldn't get handle: Permission denied

Thanks in advance
Jay

  • 4 Contributors
  • 5 Replies
  • 728 Views
  • 1 Year Discussion Span
  • Latest Post Latest Post by tkhanna

Dani AI

Generated

The SFTP message "Couldn't get handle: Permission denied" is a server-side access failure: the SFTP subsystem was refused a handle on a file or directory. It is usually not a client-script bug. Common causes are filesystem ownership/permission problems, chroot/ChrootDirectory restrictions, SELinux AVC denials, POSIX ACLs, or NFS/mount options that remap ownership. OP later noted the problem was an access issue, which fits these causes.

Quick diagnostic checklist and useful commands (run the client and server checks to collect evidence):

# reproduce with verbose client output
sftp -vvv user@host
ssh -v user@host

# check sshd logs on the server
sudo journalctl -u sshd --since "1 hour ago"
# or
sudo tail -n 200 /var/log/secure

# inspect permission chain and ACLs
namei -l /path/to/target
getfacl /path/to/target

# check ownership/modes for home/ssh keys
ls -ld /home/username /home/username/.ssh
ls -l /home/username/.ssh/authorized_keys

Practical fixes to try (safe, minimal changes): correct ownership so the account owns its files; ensure the home directory and parent directories are not group/world-writable; set .ssh to be accessible only to the user and authorized_keys to be readable only by the user; if OpenSSH is using ChrootDirectory, the chroot path and all parents must be owned by root and not writable by others, with a writable subdirectory inside for the user. If SELinux is enabled, look for AVC denies in the audit log before changing enforcement or policies. If the filesystem is NFS, check mount options like root_squash and exported ownership.

This expands on 's SELinux hint and 's permission-fix observation: avoid broad recursive chmods or permanently disabling enforcement. Collect verbose client output and the server-side sshd/audit logs for a precise diagnosis if the problem persists.

Recommended Answers

All 5 Replies

Member Avatar for Major Major

does your distro use SELinux?

if so try disabling it temporarily with

setenforce 0

if everything starts working re-enable SELinux and use the audit2allow and attendant commands to search your audit logs and make a local rules file and import it into your SELinux settings.

Member Avatar for bzptqj

Hi,

Thanks for your time to reply my question.
This issue has been resolved now.
Problem was due to some access problem

Best Regards!
Jay

Member Avatar for Major Major

congrats!

Member Avatar for kane4u

can u show me the steps what have u did

Member Avatar for tkhanna

can u show me the steps what have u did

Hi,

Even I faced the same problem, I tried the following command

chmod -R /home/apple1

where apple1 is the user which was facing the permission problem

Thanks,
Tarun

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.