CIFS/Samba warning!

[Edgar Arroyo]

This is to warn everybody if using CIFS/Samba that links will redirect locally, they will not redirect to the shared folder on the shared machine.

[Andrew Cowan]

Is there perhaps a follow/ignore links mount option in your Samba configuration files?

[Edgar Arroyo]

I haven't checked, but it sure would be wise to set it as default. I will look for it.

[Darren Prior]

Hi Edgar,

There are a number of options within smb.conf regarding links. These are documented within the man page for smb.conf. However are you referring to HP-UX links or shortcuts within Windows?

regards,

Darren.

[Edgar Arroyo]

No, just in general, I have 2 HP-UX boxes and when I copied from the 1st machine's /share to the 2nd machine's /share it asked me to replace??? That's how I noticed it was linking locally instead of remotely.

[Darren Prior]

Hi Edgar,

I'm not sure I follow... Could you explain in a little more detail?

regards,

Darren.

[Thomas Bianco]

i think i understand.

you have a samba share with a softlink on it.
when you mount this share from another system, the link is dereferenced to a file on the client rather then to a file on the server sharing the samba mount.

this is the expected behevior. softlinks reference a path, i.e. /etc/resolv.conf, which is interpereted by the shell (i think) when it's accessed. if your accessing serverA:/etc/resolv.link from clientB, and serverA:/etc/resolv.link references /etc/resolv.conf, the shell on clientB will interperate this as clientB:/etc/resolv.conf

somebody check my math?

[Edgar Arroyo]

Well, you get it, but your example is off.

When ServerB access ServerA:/etc/resolv.conf it will go to ServerB's /etc/resolv.conf, not ServerA's /etc/resolv.conf which *SHOULD* be the correct behavior when you're dealing with a shared network path, stay in the same Server.

[Thomas Bianco]

We're on the same page as far as the problem is concerned.

However, I think this is the expected behaviour. I'll quote from the ln info-page

"Symbolic links" ("symlinks" for short), on the other hand, are a
special file type (which not all kernels support: System V release 3
(and older) systems lack symlinks) in which the link file actually
refers to a different file, by name. When most operations (opening,
reading, writing, and so on) are passed the symbolic link file, the
kernel automatically "dereferences" the link and operates on the target
of the link. But some operations (e.g., removing) work on the link
file itself, rather than on its target.

This implies that the link contains a path, but not a server name.

If this is the expected behaviour, /etc/resolv.link will return /etc/resolv.conf and be directed to /etc/resolv.conf. On ClientB the same operation will result in ClientB being directed to /etc/resolv.conf (same as the local operation) but because of the different context, you get a different result.

Let's assume your behevior is correct, just for compairison; you have a file /exporteddir/resolv.conf that links to /etc/resolv.conf. If /etc is not exported, and links are being dereferenced locally, how would you access it from another server?

[Edgar Arroyo]

The correct behavior (I think) is the server (samba) follow that link and return either the file content or if a directory and access is allowed, the content of that directory.

[Thomas Bianco]

But the info page states that the kernel is dereferencing the file, not samba or NFS.

Perhaps a hard link is what you're looking for. A hard link is essentially a second file entry pointing to the same inodes on the file system. Since there is nothing to dereference, there is no ambiguity.

[Edgar Arroyo]

Isn't hard link only possible on the same partition? HP-UX has many partitions by default, usr, var, tmp, etc etc

I do links from partitions to other partitions mostly

[Edgar Arroyo]

Isn't hard link only possible on the same partition? HP-UX has many partitions by default, usr, var, tmp, etc etc

I do links from partitions to other partitions mostly because one of the partitions is about to run out of space

[Thomas Bianco]

Yes, hard links can only link files on the same file system. Because they are simple file entries, they cannot reference other file systems in the same way you have a file /etc/resolv.conf with inodes on /var (assuming /etc and /var are on different file systems.)

Paths in Unix are relative to the file system, if you have a symlink to a specific file, then umount that file system, your link (on a different file system) fails even if you've mounted it to a separate mount point.

Hard links, being themselves constrained to the file system, prevent the above relativity issue, but by design cannot reference anything off the file system.

I think you're looking for an absolute reference, but that doesn't exist. Note this is the same behaviour as windows. If you have a link on a shared drive that points to c:\winnt\system32\cmd.exe you'll get the cmd.exe on the client, not on the server.

[Edgar Arroyo]

I agree with you. But what I'm trying to say is that the *default* should be not to allow links, to hide them unless they give full support and link to correct file/path and return it's content.