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
Comments
@Nikratio curious if this is expected behavior or not. I haven't found a good work around yet; still actively looking. Thanks! |
Still having this issue... if anyone can provide some insight or help it would be greatly appreciated :/ |
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 |
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. |
The symlink target is a text file, in the same directory. when I ssh into the system and do ls, i get 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.
|
In that case there would need to be a problem with transferring the permissions (which is unlikely). Can you please confirm the output of |
For reference, when you use |
The two systems are not the same Linux OS. Maybe that can explain the differences in the |
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? |
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 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: Can I create symbolic links to files when the directory is mounted via sshfs? After mounting, I tried |
Can you create a regular file with the same name? What happens if you do |
And is this mounted with |
Yes that was with I remounted as follows
Can't find the file, this is expected: it hasn't been created yet. Create it now:
I am able to create the symlink without |
Very odd. I just noticed that in your second to last message, the |
TL;DR I had a typo before with I had a typo with I have tried the following commands with
File not found, expected. Create it and the symlink now:
Everything works as expected up to here! 😀 Again, on Fedora <-> Fedora, do the same process but with
So the error here, is that with
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 Now,
This is different behavior than before for mounting without Doing Fedora(local) <-> Synology NAS(remote) with I now believe this is specific to mounting the Synology NAS. Another Synology user describes a similar problem back in 2011. |
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. |
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 |
@soamaven I'm having the same issue with a Synology NAS. Did you find a solution? |
Nope. Never did. Something to do with the Synology NAS OS doesn't play nice
with sshfs. Good luck, let us know if you figure it out!
On Thu, Jul 6, 2017 at 13:26 Sullivan SENECHAL ***@***.***> wrote:
@soamaven <https://github.com/soamaven> I'm having the same issue with a
Synology NAS. Did you find a solution?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#12 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AOQbWkEHf9GwgaxqTUhmE6JfzxAZojd6ks5sLUKFgaJpZM4HwbPT>
.
--
Best,
Colton Bukowsky
Ph.D. Candidate, Atwater Research Group, Caltech
cb@caltech.edu
o: +1-626-395-2821 | c: +1-954-559-9054
https://linkedin.com/in/cbukowsky
|
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 vials
of that directory, but I cannot r,w, or x the links. I mount using the code below, with RSA key pairs for authentication.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:I can see it, but am denied permission.
I have tried many different
sshfs
options. Same behavior when I try running viasudo
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 thefollow_symlink
option, but when I mount without this option, I can still read the originalfile.txt
as before, but when I go to accessfile_symlink.txt
I get: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
The text was updated successfully, but these errors were encountered: