2

I have a FreeNAS 11.0-U4 box running a CIFS share, which I normally access from my Linux system via an autofs mount. A few days ago, I noticed the mount misbehaving, displaying all files with useless DOS-style permissions (rwxr-xr-x) instead of the actual underlying mode bits.

I decided to try it out by hand. I ran the mount.cifs commmand:

sudo mount.cifs -o username=theuser,uid=theuser,gid=theuser //theserver/theuser /mnt

Then I ran mount with no arguments to see what the actual mount looked like. This came back:

//theserver/theuser on /mnt type cifs (rw,relatime,vers=3.0,cache=strict,username=theuser,domain=,uid=1000,forceuid,gid=1000,forcegid,addr=10.XX.XX.XX,file_mode=0755,dir_mode=0755,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)

Note in particular the presence of nounix (which disables all UNIX extension support), file_mode, and dir_mode, all of which combine to force 0755 permissions on everything.

I am not specifying these options, and I'm pretty sure they're not lurking in a config file somewhere, so I'm very confused as to why they're appearing. This setup used to work -- certainly well enough to archive files off to the NAS without it deciding that every file is executable.

On the Linux side, mount.cifs and the various samba components are version 4.6.7. On the FreeNAS side, v11.0-U4 is running samba 4.6.8.

Where are these options coming from? Do I need to tweak something on the server side? How can I bludgeon things back into line?

1
  • I guess the defaults are hard-coded in mount.cifs. You can override the defaults by editing the mount options in /etc/auto.smb. It normally has a line at the top with opts="-fstype=cifs". You can add comma-separated options there, like for example opts="-fstype=cifs,file_mode=665,dir_mode=775" etc.
    – mivk
    Sep 16, 2018 at 13:14

2 Answers 2

1

In kernel upgrade it was changed default verion of SMB protocol to 3.0 which doesn't understand to Unix extensions. If You want to use Unix extensions append to Your options "vers=1.0".

5
  • 1
    Okay, I downvoted this because it was "obviously" nonsense. Today I actually tried it, and it worked. What I don't understand is why it worked. It's my understanding that UNIX extensions are independent of the CIFS protocol version. Can you point to a reference documenting this limitation?
    – ewhac
    Oct 27, 2017 at 7:30
  • I can confirm it works with vers=1.0. BTW @ewhac you can remove the downvote by clicking the downvote button again.
    – myrdd
    Jun 29, 2018 at 12:50
  • Samba does not yet support unix extensions for SMB3 (in fact, SMB 2.0+). It is being worked on. [lists.samba.org, 10/2017] When UNIX extensions will be finalized, the Samba implementation is ”not going to allow clients to create "real" symlinks on the server“. [same thread]
    – myrdd
    Jun 29, 2018 at 13:11
  • see also unix.stackexchange.com/questions/403509/…
    – myrdd
    Jun 29, 2018 at 13:23
  • @myrdd: My vote is locked unless the answer is edited.
    – ewhac
    Jun 29, 2018 at 19:41
0

As noted in the man page cifs can be manipulated with proc

/proc/fs/cifs

and fstab

/etc/fstab

likely you want fstab, something like;

//theserver/theuser  /mnt   cifs    guest,uid=1000,iocharset=utf8,vers=1.0  0  0
1
  • 1
    No, I definitely don't want to do it through fstab, because I don't want the mount to persist. I want it to appear and disappear on an as-needed basis. This has to work on a laptop, which is constantly hopping networks. autofs isn't a perfect solution, but it's worked better than anything else I've tried.
    – ewhac
    Oct 17, 2017 at 6:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .