SOLVED Can't connect to CIFS share

[David Dyer-Bennet]

I can SSH in, and I've verified the password works for that (not just the public key). So user "ddb" is set configured the way I think.

User ddb is the owner of /mnt/zzback/local/ddb. The protection is 755. As user ddb logged in via ssh I can access it.

I have exported ddb as a share named ddb.

But I can't connect to it from Windows 7; not by "\\zzbackup\ddb" and fill in user ddb and password (it does ask), not by entering "map network drive" and trying to connect with "use other credentials" checked (it also asks me for username / password, but then failes to connect).

Any ideas?

 

[Mirfster]

Just a question, but have you restarted your CIFs Service?

 

[David Dyer-Bennet]

No, but I could see it browsing, so it didn't occur to me that restarting would be necessary.

Huh; I see no "restart" option associated with a share. Do you mean stopping and restarting the entire service? Is this just a debug question, or do I actually have to interrupt service to all users to create a new share normally? (Currently this particular box is a test system, so no problem trying it right now). [Edited to add: looking back, I see you did say "CIFS service". So I tried what you suggest, but unfortunately no help.]

Stopping and restarting the CIFS service had no effect.

 

[Mirfster]

Was just asking because when you first configure/create; you want to ensure the CIFS Service is running. Not that you would have to do that every time.

So aside from that, under [Storage] - [Volumes] - [View Volumes]:
If you select/highlight "ddb" and choose "Change Permissions";

Are the permissions similar to this?:

 

[David Dyer-Bennet]

There's no volume ddb, it's under "local". So I can't see it directly in Storage, and can't invoke change permissions on it. I routinely export entire sub-trees on Solaris, is that not workable here?

 

[Mirfster]

Adding link to CIFS sharing in docs for reference: http://doc.freenas.org/9.3/freenas_sharing.html?highlight=sharing#windows-cifs-shares

 

[Mirfster]

There's no volume ddb, it's under "local". So I can't see it directly in Storage, and can't invoke change permissions on it. I routinely export entire sub-trees on Solaris, is that not workable here?

TBH, I am unsure. That would have to be addressed by others that are more familiar. Was just trying to assist with my limited knowledge.

 

[David Dyer-Bennet]

Simplifying cases seem to be working, so that's always hopeful :). For my use-cases I don't have so many users or shares that I'm going to care deeply at what level I can do what things, other than for curiosity.

But I'm confused, and may have created confusion, with the "home" share.

Currently in \\zzbackup I can see (in Windows network browsing) ddb and fsfs-backup (which are users I created on zzbackup), and I can get into ddb by providing the credentials for user ddb, and can't get into fsfs-backup while logged in as ddb. So far so good! However, I can somehow see a third share named "homes", also; and when I go into it, I seem to be seeing the same subtree as for user ddb. I have no share named "homes"; I do have a share named "local" which I marked as the "home share" (I believe that's where the ddb and fsfs-backup shares come from, they do point to the home directories of those two users).

So where is this "homes" share coming from?

 

[anodos]

There's no volume ddb, it's under "local". So I can't see it directly in Storage, and can't invoke change permissions on it. I routinely export entire sub-trees on Solaris, is that not workable here?

Note that in freenas you're using samba 4.1.21 and not the Solaris kernel CIFS server. The two are very different.

The reason why exporting a subdirectory for a CIFS share isn't recommended is because you want to set the zfsacl aclmode property to 'restricted' for the dataset containing your CIFS share. Samba exposes zfs acls to cifs clients as ntfs acls like a windows server. This generally makes cifs clients happier than the sort of hackery that normally needs to happen to make a unix server work like a Windows server. Setting the aclmode to restricted keeps samba from inadvertantly nuking zfs acls through chmod operations. A side effect of this is that chmod doesn't work on such a dataset. Permissions must be managed via setfacl.

Note that samba is hard-coded to use zfs acls in freenas. Working around this design may be fine in a home environment after planning / testing, but I wouldn't do it at work. Also deviation from this designed usage is a good way to get a bug report ignored ;)

So tl;dr, create datasets for your CIFS shares and set permissions type to 'windows' (which sets aclmode to 'restricted').

 

[David Dyer-Bennet]

Got it. At least starting to. (And I always have trouble with ACL stuff, somehow. Too many years of simpler schemes I guess, plus ACL is always implemented on top of other schemes, and perhaps because a lot of my experience is on Solaris which went *way far out* to get ACL doing everything and interacting with everything, and I think succeeded -- but it's a bit confusing to me.)

However, knowing not to *mix* them on FreeNAS is useful.

Using this advice, I've got access to my shares, and have gone on to create the intended backup shares, and have zfs receive working (from a zfs send on a Solaris system; but that's supposed to work, right?).

ZFS admin delegation is very handy (using the bit here https://www.freebsd.org/doc/handbook/zfs-zfs.html about how to configure to receive across an SSH link).

(All of this is preliminary test, and working up my backup scripts for across-ssh backups (old version is just going to USB disks).