Let some share with rw access and unix extensions = on be mounted on /mnt/foo.
And inside the share we have dir "bar" (/mnt/foo/bar), and a file "foobar"
One wants to create symlink to "foobar" inside "bar" (ln -s ../foobar foobar),
but what he gets is a "File not found" message (or, if he is root "Permission
Though executing "ln -s /foobar foobar" succeeds and creates symlink to the
file in root dir (/foobar), not relative to mountpoint.
Thus, ensure_link_is_save fails to do it's job properly or wrong arguments are
passed to it (or the directory change to the "bar" is not recorded properly in
connection stats struct).
Oops. ln -s /foobar foobar creates a symlink in the _same_ dir (i.e to foobar).
is this with the cifsvfs ? smbfs doesn't support unix
Yes, this applies to cifs vfs too. But symptoms are the same. Besides,
creation of hard links works fine (though, cifs_hardlink system call takes
dentry-s as params...).
Created attachment 379 [details]
patch to allow creation of symlinks
This is a patch against samba 3.0.1 with smbclient patched. It changes how smbd
handles SMB_SET_FILE_UNIX_LINK, introducing new function make_link_relative. It
relies on smbclient's way of passing data to server when creating symlinks.
Created attachment 380 [details]
patch to smbfs and cifs implementations to allow creation of symlinks
This patch is against vanilla linux-2.6.2-rc3. It makes cifs/smbfs to pass
symlink destination relative to the directory where symlink is created. This
makes the way how arguments are passed to server consistent with smbclient's
Steve & Jeremy, could you look at the smbclient / cifsvfs patches
and do whatever you think is best ? Thanks.
And let me know once your done so we can close this one out.
I'm sorry for late comment: all the patches proposed by me are broken :( the
correct (as I hope so) patch for samba is in the next attachment.
Created attachment 425 [details]
The correct patch
I don't object to the principal here but it could be controversial (since the
NFS precedent and Unix precedent in general is to have the server treat the
symlink data as opaque). Figuring out whether there is a security exposure in
these symlinks being followed on the server when Samba is serving Windows (or
non-Unix extensions aware clients)
My main worry is that converting an absolute to a relative path may not make
much sense in the client's name space (although it could on the servers) and
could intentionally end up crossing filesystems on the client when the client's
is the one following the link (ie the case of Unix extensions or NFS client)
Another possibility is the "client only" symlink idea that Apple is testing -
which relies on a "magic file size" (1065 bytes I think) as a hint to the
client to link in the data for symlink info. I personally prefer that we
handle "client only" symlinks via the reparse flag with the reparse data
containing the symlink (rather than relying on overloading file data for normal
files of a certain size to optionally include symlinks).
Unfortunately this patch is now not applicable with the latest changes
to pathname processing in the SAMBA_3_0 CVS tree. I also tested that
symlinks work (and hardlinks also) when coding up the new pathname
processing. My guess is that this will be fixed in the latest CVS
as I now process ../ within Samba.
Steve, Since jra thinks the smbclient patch is
obselete now, I'm moving this bug to cifsvfs
so you can do as you see fit.
I will fix this.
sorry - comment above was posted to the wrong defect - I doubt that the patches
are relevant now.
Created attachment 1051 [details]
updated cifs mount helper
gcc mount.cifs.c -o mount.cifs
mount.cifs goes in /sbin typically (backup your original mount.cifs)
Comment on attachment 1051 [details]
updated cifs mount helper
This mount.cifs.c goes with a different defect (bugzilla got confused).
Current Samba and cifs vfs handle these. If there is still a problem or
enhancement to symlinks you would like to see. Please reopen with the
additional data or create a new bug report.