Open drafie opened 10 years ago
Have you tried adding a trailing slash on the remote path? Is the user with which you're deploying chrooted?
Run dandelion with the --log=debug
option and comment with the results.
What shell is the deployment user running on? bash? rssh?
I've discovered an issue with deploying via SFTP when the deployment user is set to use rssh, but haven't gathered enough data to know if this is an issue with dandelion or Net::SCP. What has worked for me to address this problem is to change the deployment user to use a different shell, such as bash.
sudo chsh -s /bin/bash [user]
I can't reproduce this. I am able to use both a relative and absolute path
just fine. Please check your remote permissions and re-open this if you still believe this is an issue related to Dandelion.
Was this ever resolved? I'm getting the exact same issue, also with a project in /var/www/...
.
--log=debug
doesn't add any additional output. Works absolutely fine when copying files through Cyberduck and Forklift. Also tried temporarily changing the permissions to 777 without any luck.
Thanks
Actually, I think setting preserve_permissions
to false might have solved this. Any idea why it could write a file, but not have permission to change this?
@SteveEdson Not sure. Does Cyberduck or Forklift have an option to preserve permissions as well? It'd be nice to verify that is indeed the issue.
Cyberduck seems to be able to change the permissions without any issues
@SteveEdson OK, I'll play around with this a bit. What SFTP server software is the remote machine running?
Thanks, it's just a standard CentOS box as far as I can tell
I'm not familiar with CentOS but based on a quick search I'm guessing that means vsftpd
. Do you know for sure?
I use SFTP to dandelion deploy.
When the path (remote) is set to myapplication (path: myapplication) it works fine. When the path (remote) is set to /var/www/myapp (path: /var/www/myapp) it fails with a permission error.
However, using Filezilla and SFTP there is no problem uploading to that directory.
The failure so far occurs on a file with "." preceeding the name - such as .gitkeep. I don't know if that has anything to do with it.