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" (/mnt/foo/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 denied"). 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 extensions anyways.
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 way.
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. Jeremy.
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.