You are not logged in.

#1 2017-10-30 21:00:14

MrWeatherbee
Member
Registered: 2007-08-01
Posts: 275

CIFS Module Does Not Show Symlinks Unless Set To Vers=1.0

Problem:

I have a Samba share setup on PC1 (main PC / server) that is mounted on PC2 (client). Mounting on PC2 is handled by AutoFS. Both server and client are running Arch Linux.

The share on PC1 has a single symlink. Both PC1 and PC2 have the proper directory structure and permissions for the link to work as intended when the link is resolved locally on both server and client.

The above setup worked until the update to Kernel 4.13.9-1 (replaced 4.12.x). I am aware that the CIFS module in 4.13.x now defaults to version 3.0, whereas up until 4.13.x the default had been version 1.0.

Now, with AutoFS set to mount using anything other than version 1.0 (e.g., 2.0, 2.1, 3.0), the symlink appears as a regular folder and will only resolve on the server. Attempting to open the folder fails if Samba isn't configured to use the appropriate symlink options, and if configured with the options, the folder opens to display files on the server. Nothing I've tried with the new CIFS protocols will show the symlink as a symlink, nor will the symlink resolve locally (it always points to the server).

Questions:

Is the above described inability to have symlinks actually appear on the client as symlinks and the inability to resolve symlinks locally the expected behavior beyond version 1.0?

Can I use a CIFS protocol greater than 1.0 and have it behave as before (i.e., properly show symlinks and resolve symlinks locally) by changing some settings? Perhaps modifying the Samba configuration or AutoFS mount parameters with some options that I am not familiar with?

Is the described behavior a bug or lack of full development of the CIFS module?  I had read that version 3.0 had not fully implemented the Samba Unix Extensions, but I was surprised to see the 2.x versions behave the same way.

-----
I have read several CIFS-module-related forum posts, but none that specifically addressed the symlink behavior. Sorry if I missed a previously posted answer.

Thanks.

Offline

#2 2017-10-30 21:15:32

progandy
Member
Registered: 2012-05-17
Posts: 2,468

Re: CIFS Module Does Not Show Symlinks Unless Set To Vers=1.0

Is there a reason you are using samba instead of NFSv4 if client and server are running linux?

Edit: As far as I know CIFS requires POSIX extensions for symlinks, which aren't avaiable for the newer protocols. Maybe "mfsymlinks" will work, but I never tried it.

https://www.kernel.org/doc/readme/Docum … ifs-README
Recommendations:
...
There are additional mount options that may be helpful for SMB3 to get
improved POSIX behavior (NB: can use vers=3.0 to force only SMB3, never 2.1):
     "mfsymlinks" and "cifsacl" and "idsfromsid"

Last edited by progandy (2017-10-30 21:39:06)

Offline

#3 2017-10-30 22:02:14

MrWeatherbee
Member
Registered: 2007-08-01
Posts: 275

Re: CIFS Module Does Not Show Symlinks Unless Set To Vers=1.0

progandy wrote:

Is there a reason you are using samba instead of NFSv4 if client and server are running linux?

Edit: As far as I know CIFS requires POSIX extensions for symlinks, which aren't avaiable for the newer protocols. Maybe "mfsymlinks" will work, but I never tried it.

https://www.kernel.org/doc/readme/Docum … ifs-README
Recommendations:
...
There are additional mount options that may be helpful for SMB3 to get
improved POSIX behavior (NB: can use vers=3.0 to force only SMB3, never 2.1):
     "mfsymlinks" and "cifsacl" and "idsfromsid"

Samba vs. NFS - I simplified my example; however, I may periodically have a Windows client or two connect, plus I am a little more familiar with Samba. smile

In regards to 'mfsymlinks': I did try that only because it looked somewhat related and I was grabbing at straws by that point, but it did not change anything.
Sorry I neglected to mention that.

Based on the linked thread below, which has participation of Steve French, the 'f' in mfsymlinks (Minshall+French):

https://lists.samba.org/archive/samba-t … 19772.html

it sounds like they have weak / no support for Unix Extensions in v3.0, but seems like 2.x versions do, or should have, at least some support. That's why I said I was surprised that everything above 1.0 was still fubar'd in regard to symlinks, at least as far as I was unable to find anything to get it to work as I expected.

With release of 4.13.x, Linus made a big deal out of how archaic (dare I say stupid) people were to still be using v1.0, despite the fact that the v3.0 Kernel Module was just released. Yet, the newer protocols have not properly implemented Unix Extensions. Okay. smile

Offline

#4 2017-10-30 22:57:33

progandy
Member
Registered: 2012-05-17
Posts: 2,468

Re: CIFS Module Does Not Show Symlinks Unless Set To Vers=1.0

You can try to delete the symlink on your server and then create it on the client after mounting it with mfsymlinks. That may create a symlink that works on the client, but does nothing if accessed on the server.

Offline

#5 2017-10-31 00:16:30

MrWeatherbee
Member
Registered: 2007-08-01
Posts: 275

Re: CIFS Module Does Not Show Symlinks Unless Set To Vers=1.0

progandy wrote:

You can try to delete the symlink on your server and then create it on the client after mounting it with mfsymlinks. That may create a symlink that works on the client, but does nothing if accessed on the server.

My main goal in the original server / client setup was to replicate on the client the same maintenance environment as on the server. In other words, I wanted the directory with the symlink in it to look identical on all machines that connect to that share (including the server). So doing as you suggest defies that goal ... thus my desire to find a fix that replicates expected symlink behavior.

Beyond that, if my share had many (10s, 100s) of symlinks, then your suggestion would result in symlinks (desired on the server, and thus not deletable) looking like directories on the client and unusable at that; and the symlinks on the client would look like (and actually be) text files on the server*. In other words, the client and server would be cluttered with unusable objects and would be very confusing to the user.

However, I appreciate your suggestion and any further suggestions, even if just for experimentation's sake to see how various settings impact the behavior of the newer protocols.

So far, it looks like I'll either have to stop relying on symlinks when using the newer SMB protocols, or I'll stick with SMB1 where I just don't want to give up symlinks and use SMB3 where symlinks are not desired (the latter is actually how I'm running now).

* Note - your suggestion can be accomplished without adding the 'mfsymlinks' option, i.e. symlinks can be created locally (on the client) with normal behavior whether the option is set or not (tested with vers=3.0). The GUI menu items for creating links (at least in Nemo) are grayed out when browsing the share on the client, but the symlinks can be successfully created via 'ln -s' from the command line (again, on the client). From the perspective of the server, the symlinks created on the client are text files with metadata about the link contained therein (part of the clutter I referred to above).

Offline

Board footer

Powered by FluxBB