I am getting this error Couldn't canonicalise: Permission denied. Anyone knows what does this error mean ? It all started when my team members were testing Sftp functions on some directories and they were hitting directory no found errors within their scripts.
So when we enquired our unix administrator, he did a manual sftp on the commandline and when he tried to cd to that directory in question, that error in bold was encountered.However when we tried to cd to other directories on the same level. there was no problem.
Our current setup is a Solaris 10 OS and the directories we are accessing are on a certain mount point set up by our administrators and we were told to deploy our batch architecture in that mount point.
Does anyone have any idea what is wrong or have any resources/links which could help me further ?
The 'couldn't cannonicalize' type of errors come up when the sftp server is unable to access the file/directory mentioned in the command. The 'permission denied' is an indication that one of the directories in the path being accessed does not have read/execute permission for the user trying to access it.
Check the permissions on the directory that the user is trying to accessis giving the error and check the permissions on directories that are not. Then change the permissions to fix the problem.
thanks for your inputs, however, during our initial debugging, we could ls -l the directory in question from the command prompt and go cd into the directory.However when we tried to do sftp or getting the administrator to go in and sftp manually, the error is encountered
You ALSO say this directory hierarchy is MOUNTED. NFS ? From where ? So the users who are trying to access these directories exist on the remote machine ? When the administrator tried it 'manually', was he 'root' ?? [Root will get turned into 'nobody' on the remote machine.]
Just a few thinkg to think about / check.
ALSO. If it is a locally mounted filesystem, what are the permissions of the UNDERLYING directory ??
I do not know about Solaris 10, but Solaris 8 would block you if the UNDERLYING directory was owned by root and accessible ONLY by root. No matter WHAT the mounted directory permissions are.
Let me tack on a similar issue to the above since this is the closest thread I can find out here on the web and there was no resolution posted by the initial user.
I have 2 identical systems that are mounting an NFS filesystem aptly enough named /nfs from a Netapp appliance. I SFTP to SYSTEM1 and cd to the /nfs directory and do an 'ls' and get a directory listing. I SFTP to SYSTEM2 and cd to the /nfs directory and I get the following error message:
Couldn't canonicalise: Permission denied
I'm doing this as the same user with identical UID/GID on both servers. Dsbeerf above referenced NFS but didn't elaborate. The permissions on the /nfs mount on both systems is 777.
You have to remember that the server or in this case the network appliance owns the permissions on the mounted directory, not the local server. If the netapp doesn't know one of the servers it might not be willing to share it's files or filesystems with it.
Thank you both for your responses. The options on the /etc/exports file of the Netapp is presenting the filesystem using the following flags for both servers:
-sec=sys,rw=IPADDRESS,anon=0
The /nfs filesystem is mounted the same on both systems with the following flags:
bg,hard,intr,rsize=8192,wsize=8192,sec=sys
The 2 servers are running AIX 5.3 ML2 with OpenSSH_4.1p1/OpenSSL 0.9.7d
Intresting to note that this thread still floats ard.Nice shock in the morning ..
Down to business,
With regards to the error, moving on, we got our SA to unmount the file system from the LUN pt. Checked the file permissions on that pt and changed it to 755.
And we had to ensure that the umask for any newly created directly will be at least 755. Reason being our SFTP also does create new direcotories.
After ensuring all those were in place,we resolved the issue and moved on to solving other issues.
Pls note we were using Solaris 10.1 on that server on a E6900 box.
