Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Permissions Denied to Symbolic Links #12

Closed
soamaven opened this issue Mar 14, 2016 · 20 comments
Closed

Permissions Denied to Symbolic Links #12

soamaven opened this issue Mar 14, 2016 · 20 comments
Assignees
Labels

Comments

@soamaven
Copy link

Full Disclosure: X-Post from http://superuser.com/q/1057060/509930

I can mount a remote directory to /home/user/mnt and can see symbolic links via ls of that directory, but I cannot r,w, or x the links. I mount using the code below, with RSA key pairs for authentication.

$ sshfs -o allow_other,follow_symlink,uid=1000,gid=100 my.server.ip:/remote/dir /home/user/mnt
$ ls -alh ~/mnt/file.txt
-rwxr-x---. 1 user users 1.6K Mar 14 8:00 /home/user/mnt/file.txt
$ cat ~/mnt/file.txt
#Some Text

The remote folder is mounted without error. I can list and read the file file.txt as expected.
When I try to ls and read file_symlink.txt I get:

$ ls -alh ~/mnt/file_symlink.txt
-rwxr-x---. 1 user users 1.6K Mar 14 8:00 /home/user/mnt/file_symlink.txt 
$ cat ~/mnt/file_symlink.txt
cat: /home/user/mnt/file_symlink.txt: Permission Denied

I can see it, but am denied permission.

I have tried many different sshfs options. Same behavior when I try running via sudo also.

The glaring inconsistency to me is that ls -alh file_symlink.txt shows the symlink as a regular file, rather than as a link. I think this is a result of the follow_symlink option, but when I mount without this option, I can still read the original file.txt as before, but when I go to access file_symlink.txt I get:

$ sshfs -o allow_other,uid=1000,gid=100 my.server.ip:/remote/dir /home/user/mnt
$ ls -alh ~/mnt/file_symlink.txt
ls: cannot read symbolic link /home/user/mnt/file_symlink.txt: No such file or directory
lrwxrwxrwx. 1 user users 11 Mar 14 8:00 /home/user/mnt/file_symlink.txt
$ cat ~/mnt/file_symlink.txt
cat: /home/user/mnt/file_symlink.txt: No such file or directory

ls first says the file doesn't exist, but then lists the link with the link specification?

If anyone knows enough about sshfs to clarify the behavior I am seeing, that would be awesome! Thanks!

versions:
Fedora 23 4.4.3-300.fc23.x86_64
SSHFS version 2.5
FUSE library version: 2.9.4
fusermount version: 2.9.4
using FUSE kernel interface version 7.19

@soamaven
Copy link
Author

@Nikratio curious if this is expected behavior or not. I haven't found a good work around yet; still actively looking. Thanks!

@soamaven
Copy link
Author

Still having this issue... if anyone can provide some insight or help it would be greatly appreciated :/

@Nikratio
Copy link
Contributor

Nikratio commented Jun 5, 2016

It's a little difficult to follow your description. What is the target of the symlink? What result do you get when you ssh into the system and do ls on the symlink?

@Nikratio
Copy link
Contributor

Nikratio commented Jun 5, 2016

Also, with what uid are you logging into the server? Do you actually have permission to read the file that the symlink points to? Note that it's not world-readable.

@Nikratio Nikratio self-assigned this Jun 5, 2016
@soamaven
Copy link
Author

soamaven commented Jun 5, 2016

The symlink target is a text file, in the same directory.

when I ssh into the system and do ls, i get
[user@local] $ usls -alh file_symlink.txt
lrwxrwxrwx 1 user users 12 Feb 3 11:04 file_symlink.txt -> file.txt

I am logging into the system with the same uid as the local machine, so 1000 (the uid is 1000 on local, and 1001 on remote), and yes, I do have permissions to read the file when logged in under ssh.

[user@remote]$ ls -alh file.txt
-rwxr-xr-x 1 user users 6.6K Mar 10 16:00 file.txt

@Nikratio
Copy link
Contributor

Nikratio commented Jun 5, 2016

In that case there would need to be a problem with transferring the permissions (which is unlikely). Can you please confirm the output of ls -l file_symlink.txt after mounting with follow_symlinks? According to your first post it is -rwxr-x---, while it should be -rwxr-xr-x. Finally, are you sure you are copying & pasting correctly, or are you using a strange version oif ls? There is a weird dot after the permission in your first post, and you seem to be calling usls instead of ls in your most recent post.

@Nikratio
Copy link
Contributor

Nikratio commented Jun 5, 2016

For reference, when you use follow_symlinks, then ls will never show you a symlink if the target exists. That is intentional, because symlinks are followed. I would have to check the source to determine what's supposed to happen if the target does not exist.

@soamaven
Copy link
Author

soamaven commented Jun 5, 2016

[user@local]$ sshfs -o allow_other,uid=1000,gid=100,follow_symlinks user@remote:/remote_dir ~/mnt
[user@local]$ ls -l ~/mnt/file_symlink.txt
-rwxr-xr-x. 1 user users 6.6K Mar 10 16:00 mnt/file_symlink.txt
It looks like the symlink is followed properly, the symlink is not listed as a link.

The two systems are not the same Linux OS. Maybe that can explain the differences in the ls outputs and the period? I don't know about that... but I am copying correctly. I am definitely simply using ls on both machines however. The machine with the period output is Fedora, the machine without it is a Synology NAS system with its a Synology Linux distro.

@Nikratio
Copy link
Contributor

Nikratio commented Jun 5, 2016

Well, so it seems now you're getting a different output than when you reported this. So can you please also confirm that the problem is still present?

@soamaven
Copy link
Author

soamaven commented Jun 5, 2016

Sorry, this issue is a few months old, and I have been using a work-around (rsync between locals and the remote). The work around is responsible for the different permissions output. The files permissions are correct in this case only because I had copied the file.txt from local to remote and I forgot that I had done this and permissions were preserved.

I am using a proprietary program, which creates symbolic links during run-time, and it can't subsequently access those links. I had thought that this was a problem with sshfs mouting, But now that I am looking at this again, it looks like the symbolic links are being created by the program with the wrong permissions in the first place...

Using the proprietary program, the file permissions are as before:
-rwxr-x---. 1 user users 6.6K Mar 10 16:00 mnt/file_symlink.txt

Can I create symbolic links to files when the directory is mounted via sshfs? After mounting, I tried
[user@local]$ ln -s /home/user/mnt/file.txt /home/user/mnt/file_symlink.txt
and got :
ln: failed to create symbolic link '/home/user/mnt/file_symlink.txt': Operation not permitted

@Nikratio
Copy link
Contributor

Nikratio commented Jun 6, 2016

Can you create a regular file with the same name? What happens if you do rm file_symlink.txt followed by echo foo > symlink.txt?

@soamaven
Copy link
Author

soamaven commented Jun 16, 2016

I think so. I did this:

[user@local]$ ls ~/mnt/file_symlink.txt
ls: cannot access /home/user/mnt/file_symlink.txt: No such file or directory
[user@local]$ rm ~/mnt/file_symlink.txt
[user@local]$ echo foo > ~/mnt/file.txt
[user@local]$ ls -alh ~/mnt/file.txt
-rw-rw-r--. 1 1038 users 4 Jun 15 18:04 /home/user/mnt/file.txt

After, I also tried this:

[user@local]$ ln -s ~/mnt/file.txt ~/mnt/file_symlink2.txt
ln: failed to create symbolic link ‘/home/user/mnt/file_symlink2.txt’: No such file or directory

but when i ls the directory, it shows up, see the image below. Unmounting, and remounting still shows the same.
screenshot from 2016-06-15 18-02-47

(*Note: The uid in the screengrab is 1038 -- I have been using uid 1000 in the issue descriptions for generality/abstraction in the descriptions, but actually using 1038 locally since that is my remote uid on the server. Speaking of, the server is a Synology NAS system Diskstation Manger OS, if that is useful)

EDIT: Changed "symlink.txt" to "file.txt" to accurately represent problem.

@Nikratio
Copy link
Contributor

And is this mounted with --follow-symlinks? If yes, does it work if you mount without that option?

@soamaven
Copy link
Author

soamaven commented Jun 27, 2016

Yes that was with --follow-symlinks. I unmounted and remounted without this option. This made the previous symlinks disappear when using ls in that directory, so the ??????????? situation disappears... also a bit wierid.

I remounted as follows

[user@local]$ sshfs -o allow_other,uid=1038,gid=100 user@remote:/remote_dir ~/mnt
[user@local]$ ls ~/mnt/file_symlink.txt
ls: cannot access /home/user/mnt/file_symlink.txt: No such file or directory
[user@local]$ rm ~/mnt/file_symlink.txt
rm: cannot remove ‘/home/user/mnt/file_symlink.txt’: No such file or directory

Can't find the file, this is expected: it hasn't been created yet. Create it now:

[user@local]$ echo foo > ~/mnt/symlink.txt
[user@local]$ ls -alh ~/mnt/symlink.txt 
-rw-rw-r--. 1 1038 users 4 Jun 27 16:06 /home/user/mnt/symlink.txt
[user@local]$ ln -s ~/mnt/symlink.txt ~/mnt/file_symlink.txt
[user@local ~]$ ls -alh ~/mnt/file_symlink.txt 
ls: cannot read symbolic link /home/user/mnt/file_symlink.txt: No such file or directory
lrwxrwxrwx. 1 1038 users 21 Jun 27 16:07 /home/user/mnt/file_symlink.txt

I am able to create the symlink without --follow-symlinks but then when I go to access the file I can't. I cannot read the symbolic link yet I can see symlink using ls -alh file_symlink.txt.

@Nikratio Nikratio added bug and removed needs-info labels Jul 1, 2016
@Nikratio
Copy link
Contributor

Nikratio commented Jul 1, 2016

Very odd. I just noticed that in your second to last message, the ls <foo> command actually lists the file as <bar>. It seems there is clearly something not right. Unfortunately I can't reproduce any of this on my system.. I don't think I'll have time to do anything about this for the foreseeable future.

@soamaven
Copy link
Author

soamaven commented Jul 1, 2016

TL;DR I had a typo before with <foo> and <bar>. sshfs between two of my Fedora machines seems to work as expected, I get different behavior between Fedora and Synology NAS where I want to use sshfs. Thanks for your help!

I had a typo with ls <foo> outputting <bar>. Sorry, tried to generalize the commands and scrub personal file data (very sorry for the inconsistencies! Edited!), I would not direct attention to that typo. I quadruple checked for any other inconsistencies on this update and tried all these commands twice. Again sorry.

I have tried the following commands with follow-symlinks and without on a Fedora(local) <-> Fedora(remote) connection, as below:

[user@local ~]$ sshfs -o allow_other,uid=1002,gid=1002,idmap=user user@remote:/dir/on/remote/in/question ~/mnt
[user@local ~]$ ls -alh ~/mnt/file.txt
ls: cannot access /home/user/mnt/file.txt: No such file or directory
[user@local ~]$ ls -alh ~/mnt/file_symlink.txt 
ls: cannot access /home/user/mnt/file_symlink.txt: No such file or directory

File not found, expected. Create it and the symlink now:

[user@local ~]$ echo foo > ~/mnt/file.txt
[user@local ~]$ ln -s ~/mnt/file.txt ~/mnt/file_symlink.txt
[user@local ~]$ ls -alh ~/mnt/file*.txt 
lrwxrwxrwx. 1 1002 1002 25 Jul  1 13:43 /home/user/mnt/file_symlink.txt -> /home/user/mnt/file.txt
-rw-rw-r--. 1 1002 1002  4 Jul  1 13:43 /home/user/mnt/file.txt
[user@local ~]$ rm ~/mnt/file_symlink.txt 
[user@local ~]$ rm ~/mnt/file.txt 
[user@local ~]$ fusermount -u mnt

Everything works as expected up to here! 😀

Again, on Fedora <-> Fedora, do the same process but with follow_symlinks now:

[user@local ~]$ fusermount -u mnt
[user@local ~]$ sshfs -o allow_other,uid=1002,gid=1002,idmap=user,follow_symlinks user@remote:/dir/on/remote/in/question ~/mnt
[user@local ~]$ ls ~/mnt/file.txt
ls: cannot access /home/user/mnt/file.txt: No such file or directory
[user@local ~]$ ls ~/mnt/file_symlink.txt
ls: cannot access /home/user/mnt/file_symlink.txt: No such file or directory
[user@local ~]$ echo foo > ~/mnt/file.txt
[user@local ~]$ ln -s ~/mnt/file.txt ~/mnt/file_symlink.txt
ln: failed to create symbolic link ‘/home/user/mnt/file_symlink.txt’: No such file or directory
[user@local ~]$ ls -alh ~/mnt/file*
ls: cannot access /home/user/mnt/file_symlink.txt: No such file or directory
-rw-rw-r--. 1 1002 1002 4 Jul  1 13:50 /home/user/mnt/file.txt

So the error here, is that with -o follow_symlinks, it tells me I can't make the soft link. When I list the directory with a wildcard, it somehow knows to look for file_symlink but can't find it. This is a very specific file name to look for when file* could match nearly anything. I can reproduce the error and get the ???????? following these steps and then ls ~/mnt, as in the image below.
screenshot from 2016-07-01 13-56-18
I decided to see what the remote machine sees, so I logged into it and did this:

[user@remote ~]$ ls -alh /dir/on/remote/in/question/file*
lrwxrwxrwx. 1 user user 25 Jul  1 15:01 /dir/on/remote/in/question/file_symlink.txt -> /home/user/mnt/file.txt
-rw-rw-r--. 1 user user  4 Jul  1 15:01 /dir/on/remote/in/question/file.txt

So when making a symlink on the local, it makes the link to the literal path on local, and this is reflected on remote as above (same behavior with -o follow_symlinks and without). When sshfs tries to follow this symlink on the ls command, it can't; makes some sense. I guess this explains why everything works without -o follow_symlinks.

Now,
When I use these commands on Fedora(local) <-> Synology NAS(remote) I actually get different behavior:
(Note: Other Synology users have reccomended to use -o idmap=user and it stabilizes my connection for whatever reason, another oddity)

[user@local ~]$ sshfs -o allow_other,uid=1038,gid=1002,idmap=user user@SynologyNAS:/dir/on/synology/in/question ~/mnt
[user@local ~]$ ls ~/mnt/file.txt
ls: cannot access /home/user/mnt/file.txt: No such file or directory
[user@local ~]$ ls ~/mnt/file_symlink.txt
ls: cannot access /home/user/mnt/file_symlink.txt: No such file or directory
[user@local ~]$ echo foo > ~/mnt/file.txt
[user@local ~]$ ln -s ~/mnt/file.txt ~/mnt/file_symlink.txt
[user@local ~]$ ls -alh mnt/file*
ls: cannot read symbolic link mnt/file_symlink.txt: No such file or directory
lrwxrwxrwx. 1 1038 users 21 Jul  1 15:18 mnt/file_symlink.txt
-rw-rw-r--. 1 1038 users  4 Jul  1 15:18 mnt/file.txt

This is different behavior than before for mounting without -o follow_symlinks. Notice that mnt/file_symlink.txt can't be found and is then listed below the read error anyway, which is similar but not exactly the same behavior as Fedora<->Fedora with -o follow_symlinks.

Doing Fedora(local) <-> Synology NAS(remote) with -o follow_symlinks gives the same behavior as Fedora(local) <-> Fedora(remote) with -o follow_symlinks.

I now believe this is specific to mounting the Synology NAS. Another Synology user describes a similar problem back in 2011.

@Nikratio
Copy link
Contributor

Nikratio commented Jul 2, 2016

sigh I can tell you that you are not collecting goodwill by having people waste their time looking at (silently) edited error messages.

Closing this issue now, seems it's a bug in your NAS.

@Nikratio Nikratio closed this as completed Jul 2, 2016
@Nikratio Nikratio added invalid and removed bug labels Jul 2, 2016
@soamaven
Copy link
Author

soamaven commented Jul 2, 2016

You're right and I understand. My apologies again. Won't happen again. Thanks for your time. Thanks for maintaining this. I'll update for the community if I find out more from Synology

@soullivaneuh
Copy link

@soamaven I'm having the same issue with a Synology NAS. Did you find a solution?

@soamaven
Copy link
Author

soamaven commented Jul 7, 2017 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants