[Samba] Can't get 'root preexec' to run

[Ole Traupe]

Hi,

I am trying to automatically create nested zfs data sets as home
directories. I have a script that works fine if I execute it manually as
root (auth via public key). It also creates a short log file in the same
dir.

However, this section in my smb.conf (on the DC) doesn't seem to execute
(no data set created, no log file) on user logon (on a member server):

[homes]
comment = User Home Directories
browseable = no
writable = yes
root preexec = /usr/local/samba/scripts/createzfshome.sh %U

What might be the reason? Is this conflicting with rfc2307 use?

My DC's Samba version is 4.2.2 (on CentOS 6.7), my Samba member server
(where the logon happens; either via ssh or with FreeNX terminal
software) is Version 3.6.23.

Is Samba 3 a problem here?

Best,
Ole

--

Dr. Ole Traupe
Lab Manager

Technische Universität Berlin



--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba

[Ole Traupe]

Meanwhile I managed to search the thread titles of the last 5 years
manually for "preexec". Is there a better solution for accessing the
archive of this list?
--

Still I can't get the DC's [homes] section's 'preexec' command to run on
user logon (on one of the domain member PCs). Selinux on the DC is off,
of course. I also tried the log-on on a Win7 domain member instead of
linux, but still no sign of the script running: my log file is not
created; zfs data sets neither. I made sure that the log file is created
even if zfs data set creation fails to some reason.

What might be interfering with this? I read the explanation of the
'preexec' command in the manpages but there is no direct reference to
its use in the [homes] section.

Even remote ideas would be most welcome!

Ole

Biopsychologie und Neuroergonomie
Institut für Psychologie und Arbeitswissenschaft

Biological Psychology and Neuroergonomics
Department of Psychology and Ergonomics

Postanschrift/Mail to:

TU Berlin
Sekr. MAR 3-2
Marchstr. 23
10587 Berlin
GERMANY

Zimmer/Office: MAR 3.052
Telefon/Phone: (+49) 030 314 22721
Fax: (+49) 030 314 25274

E-Mail: ole.t...@tu-berlin.de
www.bpn.tu-berlin.de

[L.P.H. van Belle]

You tried the pam module mkhomedir ?

And have your tried :

root preexec = "/usr/local/samba/scripts/createzfshome.sh %U"

or

root preexec = /usr/local/samba/scripts/createzfshome.sh "%U"

Is the homedir on a NFS mounted dir? Exports correctly set?



Greetz,

Louis


> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-...@lists.samba.org] Namens Ole Traupe
> Verzonden: dinsdag 20 oktober 2015 10:36
> Aan: sa...@lists.samba.org
> Onderwerp: Re: [Samba] Can't get 'root preexec' to run

[Ole Traupe]

Am 20.10.2015 um 11:01 schrieb L.P.H. van Belle:
> You tried the pam module mkhomedir ?
>
> And have your tried :
> root preexec = "/usr/local/samba/scripts/createzfshome.sh %U"
> or
> root preexec = /usr/local/samba/scripts/createzfshome.sh "%U"

The latter, with and without quotes around the %U.

>
> Is the homedir on a NFS mounted dir? Exports correctly set?

The base dir for the homes is a zfs data set shared via Samba 4 and
mounted as cifs to /home on the domain member server (CentOS 6.7). I
also tried the log-on on a Windows 7 client, so the user home was
addressed as \\server\homebase\userhome in the "Profile" tab of the user
properties in the MS ADUC console.

As I initially wanted to create a (nested) zfs data set via a
"preexec"-invoked script, I haven't tried the mkhomedir pam module.

The thing is, that my preexec parameter is not working at all, and that
primarily I want to find out, why that is - under what circumstances it
should work and what interferes with it.

Plus: if I can't get it to work, I can't use nested data sets in a
proper manner, and thus will revert to simple subfolders of the home
base dir \\server\homebase (which Samba creates just fine).

Anyways, thanks for you help, Louis!

[Rowland Penny]

On 15/10/15 11:05, Ole Traupe wrote:
> Hi,
>
> I am trying to automatically create nested zfs data sets as home
> directories. I have a script that works fine if I execute it manually
> as root (auth via public key). It also creates a short log file in the
> same dir.
>
> However, this section in my smb.conf (on the DC) doesn't seem to
> execute (no data set created, no log file) on user logon (on a member
> server):
>
> [homes]
> comment = User Home Directories
> browseable = no
> writable = yes
> root preexec = /usr/local/samba/scripts/createzfshome.sh %U
>
> What might be the reason? Is this conflicting with rfc2307 use?
>
> My DC's Samba version is 4.2.2 (on CentOS 6.7), my Samba member server
> (where the logon happens; either via ssh or with FreeNX terminal
> software) is Version 3.6.23.
>
> Is Samba 3 a problem here?
>
> Best,
> Ole
>

Hmm, struggling to understand just what you are trying to, I think you
are trying to do this:

You have the users home directories stored on the DC
The users log onto a samba member server (running 3.6.23)
You then expect the users home directory to be created on the DC

Is the above correct, if it isn't, can you state just what you expect to
happen, line by line as above.

Rowland

[L.P.H. van Belle]

Looks like my nfsv4 kerberos and root access problem.

In that case, root didnt have a kerberos ticket, and was not allowed to access the needed folder. I think this is a bit the same.

Creating the users and profiles shares from ADUC is working fine for me but
not scripted from user root.

Greetz,

Louis


> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-...@lists.samba.org] Namens Ole Traupe

> Verzonden: dinsdag 20 oktober 2015 16:50

[Rowland Penny]

On 20/10/15 16:29, L.P.H. van Belle wrote:
> Looks like my nfsv4 kerberos and root access problem.
>
> In that case, root didnt have a kerberos ticket, and was not allowed to access the needed folder. I think this is a bit the same.
>
> Creating the users and profiles shares from ADUC is working fine for me but
> not scripted from user root.
>
>
> Greetz,
>
> Louis
>
>
>

Hi Louis, it might help if you re-read the opening post, I mean what is
an 's' between friends :-)

I would then suggest the OP goes and reads this:
https://wiki.samba.org/index.php/User_home_drives

I think that I now understand what he is trying to do: The user logins
in to a domain member (aka member server) where the users homedir does
not exist, but there is a mount on /home and he is trying to get the
users homedir created on the DC the first time the user connects, hmm I
wonder if pam_mkhomedir will do this???

Rowland

Rowland

[L.P.H. van Belle]

Hai Rowland,

The pam_mkhomedir worked ( by accident ) on for home dir on my print server.
But i cant remember if that was a mounted /home or a local /home.
Worth a try i think .. simple change and test.
Thats why i suggested it.. ;-)

Greetz,

Louis


> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-...@lists.samba.org] Namens Rowland Penny
> Verzonden: dinsdag 20 oktober 2015 18:03

> Aan: sa...@lists.samba.org
> Onderwerp: Re: [Samba] Can't get 'root preexec' to run
>

[Rowland Penny]

On 20/10/15 21:08, L.P.H. van Belle wrote:
> Hai Rowland,
>
> The pam_mkhomedir worked ( by accident ) on for home dir on my print server.
> But i cant remember if that was a mounted /home or a local /home.
> Worth a try i think .. simple change and test.
> Thats why i suggested it.. ;-)

I know it will work on a normal login to a domain member with a static
/home, but I have never tried it with a mounted /home. In theory it
should create the home dir on the mount and this should create it on the
DC, but in practice ??

The other thing I was trying to point out was that you shouldn't use
[homes] on the DC and the OP is.

Rowland

[Ole Traupe]

Louis, thanks for the idea!

I can execute the script as root on linux (tested this), because I do
folder (zfs data set) creation via remote ssh commands, so not in the
domain context.

But the point is that the script won't even execute. Even on failure,
there would be a log file created by my script which can't be found
anywhere.

Ole

Biopsychologie und Neuroergonomie
Institut für Psychologie und Arbeitswissenschaft

Biological Psychology and Neuroergonomics
Department of Psychology and Ergonomics

Postanschrift/Mail to:

TU Berlin
Sekr. MAR 3-2
Marchstr. 23
10587 Berlin
GERMANY

Zimmer/Office: MAR 3.052
Telefon/Phone: (+49) 030 314 22721
Fax: (+49) 030 314 25274

E-Mail: ole.t...@tu-berlin.de
www.bpn.tu-berlin.de

[Ole Traupe]

Hi Rowland,

thank you for your effort! However, this is entirely not what I am
trying to achieve.

What I am trying to achieve is to get the "prexec" method to work.

The reason behind this is that I would like to have a zfs data set
created per user in an automatic (scripted) way. The reason behind that
is that if I do this by hand - from a domain admin account and with the
ACL recommendations of the Samba wiki (inheritance of owner rights), a
simple user funnily has no read or write rights on the files and folders
in his home dir. Apparently, because he wasn't the owner at the time of
creation of his home dir. But the above-mentioned domain admin account
is the owner of the users files. And by making him (the user) the owner
post-hoc I wasn't able to solve this. Samba doesn't seem to recognize
(inherite) the owner changes properly. Or I'm just too stupid to get
this done properly.

Now I will try to list my setup and intentions in a step-by-step way as
you recommended:

- srvA: CentOS 6 Samba 4 DC
- srvB: CentOS 6 domain member file server sharing zfs data sets via
Samba 4 (not via zfs' built-in module)
- srvC: CentOS 6 domain member compute and terminal server running Samba
3.6.23
- cliA: Windows 7 domain client, where I do the management via ADUC
console, and where I can test Windows log-ons
- I want to log on to srvC and cliA and have the same home dir for each
users
- I want these home dirs to be zfs data sets on srvB (for various
reasons we probably shouldn't discuss here on the list)

I know in theory, how to achieve this. My script - on the DC - works as
such if I execute it by hand. It remotely executes commands via ssh
(public key authentication). My domain is also working correctly
according to all tests found on the Samba wiki. My only problem is, that
this darn "preexec" method in the [homes] section of my DC is not
executing on user logon on srvC or cliA. I have it create two different
log files depending on success and failure of the first script line that
begins an if clause containing the rest of the commands. But this log
file is not created anyhere on the DC.

So, after all, I actually am trying to figure out, why that is.

If I seem unappreciative of your attempt to help me, let me assure you
that it is not the case. I just figured that it would be enough to ask
whether someone has an idea of why "preexec" isn't working in my case.
And that probably is because I am new to this and very likely
overlooking the obvious here.

Best regards,
Ole

[Rowland Penny]

I think you may still be missing the obvious, '[homes]' *does not work*
on a DC.

Thinking about this, is it possible that your 'root preexec' command is
being run, but just not when you think it should ?
What I mean is, you think is should be run when a user tries to connect
to the share, but the share has already been mounted on the client and
the user connects to that. Try changing the command to something that
just echo's something to a text file in /tmp on the DC, restart the DC
and the member server and then see if there is anything in /tmp on the
DC, if there isn't anything, connect a client and check again, if still
nothing, then 'root preexec' has problems.

[Ole Traupe]

Maybe I finally figured it out. I found that sentence

"For example, the [test] and [homes] sections are unique disk shares;
they contain options that map to specific directories on the Samba server."

here:

https://www.samba.org/samba/docs/using_samba/ch06.html

Does that mean that this "preexec" in the [homes] section is not invoked
if the user is accessing his or her home dir that is _configured_ on the
DC ("known" by the DC), but only if the home dir is actually
_located/shared_ there under \\dc\homes?

Seems logical now. :-/

So I could put my preexec part under [netlogon], right?

[Ole Traupe]

Am 20.10.2015 um 22:23 schrieb Rowland Penny:
> On 20/10/15 21:08, L.P.H. van Belle wrote:
>> Hai Rowland,
>>
>> The pam_mkhomedir worked ( by accident ) on for home dir on my print
>> server.
>> But i cant remember if that was a mounted /home or a local /home.
>> Worth a try i think .. simple change and test.
>> Thats why i suggested it.. ;-)
>
> I know it will work on a normal login to a domain member with a static
> /home, but I have never tried it with a mounted /home. In theory it
> should create the home dir on the mount and this should create it on
> the DC, but in practice ??
>
> The other thing I was trying to point out was that you shouldn't use
> [homes] on the DC and the OP is.

Rowland, aside from my last message to the list (and from talking about
me in the third person), could you kindly elaborate a bit on why that
is? I recognize that you have far more knowledge here than I have. I was
just hoping that you share some of it with me.

[Rowland Penny]

On 21/10/15 11:13, Ole Traupe wrote:
> Maybe I finally figured it out. I found that sentence
>
> "For example, the [test] and [homes] sections are unique disk shares;
> they contain options that map to specific directories on the Samba
> server."
>
> here:
>
> https://www.samba.org/samba/docs/using_samba/ch06.html
>
> Does that mean that this "preexec" in the [homes] section is not
> invoked if the user is accessing his or her home dir that is
> _configured_ on the DC ("known" by the DC), but only if the home dir
> is actually _located/shared_ there under \\dc\homes?
>
> Seems logical now. :-/
>
> So I could put my preexec part under [netlogon], right?
>
>

OK, did some investigation here, I tried to connect to my home share on
a machine running Linux MInt 17 from another machine running debian
wheezy, I also created a simple script to echo something to /tmp.
[homes] on the mint machine looks like this:

[homes]
comment = Home Directories
browseable = yes
read only = no
root preexec = /usr/local/scripts/welcome.sh %U

The script:

#!/bin/bash

SAMBAUSER=$1

echo "Welcome ${SAMBAUSER}" > /tmp/welcome.txt

exit 0

When I tried to browse to [homes], it showed in Caja, but would not let
me enter to get to my home share and nothing appeared in /tmp

I changed [homes] to [home] , added the line 'path = /home', restarted
everything and tried again, this time I could enter the 'home' share and
the 'welcome.txt' file was created in /tmp.
I then changed 'browseable = yes' to 'browseable = no', removed the txt
file in /tmp, restarted samba and then browsed directly to my home
share, again it worked and the txt file was created in /tmp

HTH

Rowland

[Ole Traupe]

Rowland, I apologize: I have overlooked this answer of yours before my
last post.

>> I think you may still be missing the obvious,

I was suspecting that.

>> '[homes]' *does not work* on a DC.

You mean in general or in my assumed use case?

[Rowland Penny]

On 21/10/15 12:13, Ole Traupe wrote:
> Rowland, I apologize: I have overlooked this answer of yours before my
> last post.
>
> >> I think you may still be missing the obvious,
>
> I was suspecting that.
>
> >> '[homes]' *does not work* on a DC.
>
> You mean in general or in my assumed use case?
>
>
>

I am now beginning to think it doesn't work at all, if samba4 is
involved in any way. I knew that it wouldn't work on a DC (probably
because the user is DOMAIN\username and not just username), but from my
experiment (see my earlier post) it doesn't seem to work at all, try
your setup with '[home]' and a path line.

[mourik jan heupink]

Hi,

On 10/21/2015 01:21 PM, Rowland Penny wrote:
> I am now beginning to think it doesn't work at all, if samba4 is
> involved in any way. I knew that it wouldn't work on a DC (probably
> because the user is DOMAIN\username and not just username), but from my
> experiment (see my earlier post) it doesn't seem to work at all, try
> your setup with '[home]' and a path line.
>
> Rowland
>

Probably I misunderstand the above, but I can only say: we're on
samba4.1.17, and on our fileserver we use this:

> [homes]
> root preexec = /usr/local/sbin/mkhomedir.sh %U
> comment=Home directory for %S
> read only = No
> browseable = No
> create mask = 0770
> directory mask = 0770

And this works as expected: the preexec runs, and the homes share gives
us per user home folders.

MJ

[Rowland Penny]

On 21/10/15 12:41, mourik jan heupink wrote:
> Hi,
>
> On 10/21/2015 01:21 PM, Rowland Penny wrote:
>> I am now beginning to think it doesn't work at all, if samba4 is
>> involved in any way. I knew that it wouldn't work on a DC (probably
>> because the user is DOMAIN\username and not just username), but from my
>> experiment (see my earlier post) it doesn't seem to work at all, try
>> your setup with '[home]' and a path line.
>>
>> Rowland
>>
>
> Probably I misunderstand the above, but I can only say: we're on
> samba4.1.17, and on our fileserver we use this:
>
>> [homes]
>> root preexec = /usr/local/sbin/mkhomedir.sh %U
>> comment=Home directory for %S
>> read only = No
>> browseable = No
>> create mask = 0770
>> directory mask = 0770
>
> And this works as expected: the preexec runs, and the homes share
> gives us per user home folders.
>
> MJ
>

OK, further tests, Mourik is correct, if you use '[homes]' and browse
direct to the users share it works, whats more, exactly the same setup
works on a DC!, so it would seem that you can use '[homes]' on a DC, you
just cannot browse to the 'homes' share (well, I cannot).

I feel more tests coming on. :-)

Rowland

[Rowland Penny]

Just had a further thought, has the OP made his script executable ?
probably he has, but easy to forget.

[Ole Traupe]

Rowland, thanks for your effort, I highly appreciate it!

From what I had read before...

[home] would be an arbitrarily named share and its preexec command would
execute whenever a domain user connects to it
[homes] is a special purpose section in the smb.conf that comes into
play whenever a domain user connects to his or her home dir defined on
the DC

What MJ is telling seems to confirm this distinction.

(continued in my response to him)

[Ole Traupe]

MJ, thanks a lot! Just to make sure I get you right:

This section is in the smb.conf.
a) on the DC acting as file sever as well, or
b) on a separate file server running Samba 4.1.17?

The user log-on happens on a third machine, that is neither DC nor that
file server, right?

How and where is the home dir for each user specified? On the DC? In the
smb.conf or via the ADUC console in the user properties under "Profile"
and/or "Unix attributes"? Are you using rfc2307 in your smb.conf?

Does this work for log-ons on Windows as well as Linux machines?

Thank you for any more details!

Ole

[Rowland Penny]

On 21/10/15 13:32, Ole Traupe wrote:
> Rowland, thanks for your effort, I highly appreciate it!
>
> From what I had read before...
>
> [home] would be an arbitrarily named share and its preexec command
> would execute whenever a domain user connects to it
> [homes] is a special purpose section in the smb.conf that comes into
> play whenever a domain user connects to his or her home dir defined on
> the DC
>
> What MJ is telling seems to confirm this distinction.
>
>
>
>

If you read this Samba wiki page:
https://wiki.samba.org/index.php/User_home_drives

It says this:

Do not name the share "[homes]", as this is a special share (see the
smb.conf manpage)!
<https://www.samba.org/samba/docs/man/manpages/smb.conf.5.html> The
"[homes]" share on an AD DC cannot handle the automatic folder creation
we will setup below and as such will not work!

I am now beginning to believe the above is not true. Before a user can
connect to their homeshare it must exist, it is the link to this, that
Samba creates i.e. it changes '[homes]' to the username and connects to
that. This is working for me on a Debian 4.1.17 DC just as it has always
done on a member server, I just never tried it before.

[mourik jan heupink]

Hi Ole,

On 10/21/2015 02:38 PM, Ole Traupe wrote:
> MJ, thanks a lot! Just to make sure I get you right:
>
> This section is in the smb.conf.
> a) on the DC acting as file sever as well, or
> b) on a separate file server running Samba 4.1.17?

on a separate fileserver. DC's are 4.2.4, fileserver 4.1.17.

> The user log-on happens on a third machine, that is neither DC nor that
> file server, right?

Doesn't matter: we have never had any issues with this setup, works from
whatever client we use. (windows doman logons, smbclient, cifs mount,
etc, etc)

> How and where is the home dir for each user specified? On the DC? In the
> smb.conf or via the ADUC console in the user properties under "Profile"
> and/or "Unix attributes"? Are you using rfc2307 in your smb.conf?

ADUC. And yes: we are using rfc2307.

> Does this work for log-ons on Windows as well as Linux machines?

Yep. As long as the linux clients use cifs to mount the share, obviously.

[Ole Traupe]

Yes, he has. He can even run it successfully by hand.

>
> Rowland

>
>

--

Dr. Ole Traupe

Lab Manager

Technische Universität Berlin

Biopsychologie und Neuroergonomie
Institut für Psychologie und Arbeitswissenschaft

Biological Psychology and Neuroergonomics
Department of Psychology and Ergonomics

Postanschrift/Mail to:

TU Berlin
Sekr. MAR 3-2
Marchstr. 23
10587 Berlin
GERMANY

Zimmer/Office: MAR 3.052
Telefon/Phone: (+49) 030 314 22721
Fax: (+49) 030 314 25274

E-Mail: ole.t...@tu-berlin.de
www.bpn.tu-berlin.de

[Ole Traupe]

Ok. Thank you very much!

So - just guessing - is this working in your case, as you actually named
the share on the file server 'homes' as the [homes] section in the
smb.conf? No, that can't be the case. There is no 'path' parameter in
that section of yours.

Out of curiosity: who is the owner of your auto-created homes according
to a) Windows and b) Linux?


@Rowland: I think what the wiki means is: if you just define an
arbitrary share on your file server, mount this on your linux member
server to e.g. /xyz, and then on the DC via the Unix Attributes (using
rfc2307) define the user home as /xyz/newuser, this home dir is
automatically created. I did this in the past. Of course, you have to
cifs-mount the share with the right permission for the user to be able
to auto-create his home during his first logon.

In contrast, the [homes] section is not intended to be used as an actual
share definition, as it is a designated special-purpose section. And,
thus, the just described auto-creation of user homes wouldn't/shouldn't
work. But it can work with root preexec, which isn't described on that
wiki page you cite.

Now you tell me that you even have a preexec parameter in the [homes]
section on the DC that is working?! Are the actual homes in this case
located on the DC?

I am on the verge of losing my mind.

[Ole Traupe]

Oh, and of course the auto-creation works if you put the path
\\server\home\user into the "Profiles" tab of the user properties in the
ADUC console. This is explicitly, what the samba wiki suggests, as it is
directed to using Windows clients. As soon as you press "Ok", the folder
is created

[Rowland Penny]

On 21/10/15 16:49, Ole Traupe wrote:
> Oh, and of course the auto-creation works if you put the path
> \\server\home\user into the "Profiles" tab of the user properties in
> the ADUC console. This is explicitly, what the samba wiki suggests, as
> it is directed to using Windows clients. As soon as you press "Ok",
> the folder is created
>
>

A users profile is different from a users Unix homedir and normally you
need to create the subdirectory manually and then when the user logs
in/out the users profile is created. I don't understand when you say 'As
soon as you press "Ok", the folder is created' , what 'OK' button and
where is the folder created?

[Ole Traupe]

I think I finally managed to understand the [homes] part of the man
pages, and what my problem is:
https://www.samba.org/samba/docs/man/manpages/smb.conf.5.html

The misunderstanding comes from my practice I learned on Windows to just
share the "\\server\home" directory and to create per-user sub-folders
(\\server\home\newuser) that *themselves are not shared*.

If you - as you obviously should (at least referring to Samba) - put
"\\server\newuser" as home dir path into your user config on the DC, the
manpages start beginning to make sense: The Samba file server receiving
the request to connect to \\server\newuser finds no appropriate share
entry in the smb.conf and, thus, clones the content of the [homes]
section (given the username exists and the password is correct) for
creating a new share (actually shared, no simple subfolder of a share).

So the user home must actually be a share and the [homes] section with
the 'root preexec' parameter has to be defined on the Samba server
hosting those home shares.

Will try this tomorrow.

Ole

[Ole Traupe]

On a Windows domain member client in the ADUC console, you specifiy the
home dir path that is to be used on Windows machines on the "Profile"
tab. As soon as you click 'Ok' (or 'Apply' for that matter), the folder
is created (by the DC via your domain admin account) on the Samba server
hosting the share the path you provided leads to. Try it, its nice an
simple. However, not useful in my case, as I want to create a zfs data set.

[Rowland Penny]

On 21/10/15 17:40, Ole Traupe wrote:
> On a Windows domain member client in the ADUC console, you specifiy
> the home dir path that is to be used on Windows machines on the
> "Profile" tab. As soon as you click 'Ok' (or 'Apply' for that matter),
> the folder is created (by the DC via your domain admin account) on the
> Samba server hosting the share the path you provided leads to. Try it,
> its nice an simple. However, not useful in my case, as I want to
> create a zfs data set.
>
>
>

I usually set the users profile attribute directly when creating the
user and as such, have never used ADUC to do this, but I am still
struggling to understand how a windows machine can create the full
directory path to a users profile on a Unix machine.

[Ole Traupe]

It is actually the DC creating a sub-folder for the user.

[Rowland Penny]

On 21/10/15 17:37, Ole Traupe wrote:
> I think I finally managed to understand the [homes] part of the man
> pages, and what my problem is:
> https://www.samba.org/samba/docs/man/manpages/smb.conf.5.html
>
> The misunderstanding comes from my practice I learned on Windows to
> just share the "\\server\home" directory and to create per-user
> sub-folders (\\server\home\newuser) that *themselves are not shared*.
>
> If you - as you obviously should (at least referring to Samba) - put
> "\\server\newuser" as home dir path into your user config on the DC,
> the manpages start beginning to make sense: The Samba file server
> receiving the request to connect to \\server\newuser finds no
> appropriate share entry in the smb.conf and, thus, clones the content
> of the [homes] section (given the username exists and the password is
> correct) for creating a new share (actually shared, no simple
> subfolder of a share).
>
> So the user home must actually be a share and the [homes] section with
> the 'root preexec' parameter has to be defined on the Samba server
> hosting those home shares.
>
> Will try this tomorrow.
>

Ah, light dawns, you are confusing the 'homeDirectory' and the
'unixHomeDirectory' attributes, windows uses the first one and should as
you say contain something like ' \\server\newuser', whereas Unix uses
the last one and should contain the full Unix path to the users homedir
i.e. '/home/newuser'.

So what you are proposing to try tomorrow should work if you bear the
above in mind.

Rowland

[Ole Traupe]

Well, I do. That is not the problem.

The problem was that I wasn't used to have user homes to be shares
themselves. And when I share \\server\home and want to have the folder
\\server\home\newuser to be auto-created, but I actually connect to the
share [home] (\\server\home), this section in the smb.conf is always
found and so the special [homes] section is never executed (cloned).

I'll report tomorrow.

Ole

[Harry Jede]

On 19:10:05 wrote Ole Traupe:

> Ok. Thank you very much!
>
> So - just guessing - is this working in your case, as you actually
> named the share on the file server 'homes' as the [homes] section in
> the smb.conf? No, that can't be the case. There is no 'path'
> parameter in that section of yours.
>
> Out of curiosity: who is the owner of your auto-created homes
> according to a) Windows and b) Linux?
>
>
> @Rowland: I think what the wiki means is: if you just define an
> arbitrary share on your file server, mount this on your linux member
> server to e.g. /xyz, and then on the DC via the Unix Attributes
> (using rfc2307) define the user home as /xyz/newuser, this home dir
> is automatically created. I did this in the past. Of course, you
> have to cifs-mount the share with the right permission for the user
> to be able to auto-create his home during his first logon.
>
> In contrast, the [homes] section is not intended to be used as an
> actual share definition, as it is a designated special-purpose
> section. And, thus, the just described auto-creation of user homes
> wouldn't/shouldn't work. But it can work with root preexec, which
> isn't described on that wiki page you cite.
>
> Now you tell me that you even have a preexec parameter in the [homes]
> section on the DC that is working?! Are the actual homes in this case
> located on the DC?
>
> I am on the verge of losing my mind.

Never mind.

I am pretty sure that the preexec function is working on all shares. You
may get confused by the share names for the users home. I believe that
this is right (not tested):

use [homes] on all smb servers, but not on DCs
use [home] only on DCs

where DC means AD style DCs, not NT4 style PDC/BDC

and remember that winbind use this path as default for [home[s]]:
/home/%D/%U

Reread Rowlands mail:
https://lists.samba.org/archive/samba/2015-October/195162.html

--

regards
Harry Jede

[Rowland Penny]

On 21/10/15 18:19, Ole Traupe wrote:
> Well, I do. That is not the problem.
>
> The problem was that I wasn't used to have user homes to be shares
> themselves. And when I share \\server\home and want to have the folder
> \\server\home\newuser to be auto-created, but I actually connect to
> the share [home] (\\server\home), this section in the smb.conf is
> always found and so the special [homes] section is never executed
> (cloned).
>
> I'll report tomorrow.
>
> Ole
>
>

When you connect from windows to a '[homes]' share on a Unix machine,
you might think you are connecting to \\server\home\newuser, but what
happens is that Samba changes 'homes' to the users name and uses the
contents of 'unixHomeDirectory' as the path to the share. Using '[home]'
is similar but like an ordinary share, you must give a path in the
share. The path in '[home]' or 'unixHomeDirectory' must be entered in
Unix format and does not state the servername as it will only work on
the machine that Samba is running on, this means that the path must be
something like '/home/newuser'.

So when you connect from windows using '\\server\home\newuser' to a
'[homes]' share and the user has a 'unixHomeDirectory' attribute
containing '/home/newuser', you are really connecting to the directory
/home/newuser on the Samba server that holds the '[homes]' share.

[mourik jan heupink]

On 10/21/2015 02:52 PM, Rowland Penny wrote:
> I am now beginning to believe the above is not true. Before a user can
> connect to their homeshare it must exist, it is the link to this, that
> Samba creates i.e. it changes '[homes]' to the username and connects to
> that. This is working for me on a Debian 4.1.17 DC just as it has always
> done on a member server, I just never tried it before.

This is what we observe, yes. The only problem with this that ADUC
autocreation does NOT work with this, rather unfortunate.

If someone knowns of a way to make ADUC NOT create the homdir, we would
like to know. The preexec in smb.conf does it, and ADUC should simply
accept whatever we type for homedir.

MJ

[Ole Traupe]

Am 22.10.2015 um 10:00 schrieb mourik jan heupink:
>
>
> On 10/21/2015 02:52 PM, Rowland Penny wrote:
>> I am now beginning to believe the above is not true. Before a user can
>> connect to their homeshare it must exist, it is the link to this, that
>> Samba creates i.e. it changes '[homes]' to the username and connects to
>> that. This is working for me on a Debian 4.1.17 DC just as it has always
>> done on a member server, I just never tried it before.
>
> This is what we observe, yes. The only problem with this that ADUC
> autocreation does NOT work with this, rather unfortunate.
>
> If someone knowns of a way to make ADUC NOT create the homdir, we
> would like to know. The preexec in smb.conf does it, and ADUC should
> simply accept whatever we type for homedir.

Probably, the best way would be to use scripting under Windows:
http://blogs.technet.com/b/heyscriptingguy/archive/2005/12/02/how-can-i-change-the-location-of-a-user-s-home-drive-in-active-directory.aspx

You should be able to do, whatever you do in the ADUC console on a
Windows client, via scripts, too: create the DC context, interactively
logon, and set user properties.

I formerly learned some things with the outdated MS scripting guide:
https://technet.microsoft.com/en-us/library/ee221103.aspx

More up-to-date would be a Power Shell approach (can't see right away,
whether the above link is using this). However, I have no knowledge in
that and can't tell you how it works.

Another way, of course, might be to set the windows home dir path after
the first user logon during which the share is created. But that is not
at all comfortable or practiable.

[L.P.H. van Belle]

Hai, i'll try to explain so here..

When you use ADUC console. This is what happens.

( for Profile tab in ADUC )

The ADUC user creates the user network dir, but only what you set the
Drive letter: (connected with) \\servername.domain.tld\users\%username%
If you set the local pad, its not created.
This folder is created at the moment you clik OK, or Apply.

For the profil folder, this is NOT created by the ADUC tool, but by the computer where the user is logging off. ( only created at logoff )
Normaly you set something like :
\\servername.domain.tld\profiles\%username%

Users can access these shares.. but only see there own folders IF the share and folder rights are set correctly.

For example. All my users have 770 on \\servername.domain.tld\users\%username%
Which gives in my case, username:Domain Users ( the unix primary group )

The share rights tells that "everybody" has all rights.
( you can change this to domain user for example, but i need everybody )

The Access rights ( security tab ) there we set domain users with the advanced settings to : Only this folder.

So resulted in ( for windows ) user see only there folders, for linux users access to all user folders. Which i need for distributing file etc in user dirs.

For the profile path
\\servername.domain.tld\profiles\%username%
Here key is, user "SYSTEM" is use for creating the profiles folders.
Which is the account the computer users and most importand that "SYSTEM" has all rights. ( and which exists on all windows computers )
And the profile folder is created at Logoff, not like the users folder at klik OK/Apply.
The "LOCAL PATH" is normaly ony used for terminal server.

The Unix tab
In this case.
\\servername.domain.tld\users\%username%
Which is /home/users/%username%

Users is shared
And GID is set to "domain users"

So hope this is more clear...

And i really advice to NOT user \\servername\home (or \homes )
Why? You can set \\servername\%username% for the user home dir BUT no auto-created home dir.

And you dont want \\servername\username , for XP this was ok, because of path traversal problems but as Win Vista/7 and up easely blok that.
(see above)

Greetz

Louis




> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-...@lists.samba.org] Namens Rowland Penny

> Verzonden: woensdag 21 oktober 2015 18:52

> Aan: sa...@lists.samba.org
> Onderwerp: Re: [Samba] Can't get 'root preexec' to run
>

[L.P.H. van Belle]

Group policies + VBscript can do this for you.

And more ease, use the variables of windows to get the info you need.
Open an box : cmd , type set.
See HOMEDRIVE HOMESHARE .. etc.

Use a VBScript to do the magic.
Make a Computer policy to run the VBscript which gives needed rights etc.

I do something simaler but i use that for import/deleting certificates.

See the certificates examples:
http://terenceluk.blogspot.nl/2012/05/how-to-remove-trusted-certificate.html
and
https://www.jasonpearce.com/2012/02/02/import-pfx-certificate-via-group-policy-preferences/

Greetz,

Louis


> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-...@lists.samba.org] Namens Ole Traupe
> Verzonden: donderdag 22 oktober 2015 10:41

> Aan: sa...@lists.samba.org
> Onderwerp: Re: [Samba] Can't get 'root preexec' to run
>
>
>

[Rowland Penny]

You do not have to create users with ADUC, you could use samba-tool and
set quite a lot with this, try running 'samba-tool user create --help'
for a full list of what you can set. You can also write your own scripts
to do this, either around samba-tool or by using ldifs and ldap or ldb
tools.

Rowland

[Ole Traupe]

Louis, I agree with you, with some exceptions:

Am 22.10.2015 um 10:44 schrieb L.P.H. van Belle:
> Hai, i'll try to explain so here..
>
> When you use ADUC console. This is what happens.
>
> ( for Profile tab in ADUC )
>
> The ADUC user creates the user network dir, but only what you set the
> Drive letter: (connected with) \\servername.domain.tld\users\%username%
> If you set the local pad, its not created.
> This folder is created at the moment you clik OK, or Apply.
>
> For the profil folder, this is NOT created by the ADUC tool, but by the computer where the user is logging off. ( only created at logoff )
> Normaly you set something like :
> \\servername.domain.tld\profiles\%username%

You probably mean 'logon', right?

>
> Users can access these shares.. but only see there own folders IF the share and folder rights are set correctly.
>
> For example. All my users have 770 on \\servername.domain.tld\users\%username%
> Which gives in my case, username:Domain Users ( the unix primary group )
>
> The share rights tells that "everybody" has all rights.
> ( you can change this to domain user for example, but i need everybody )
>
> The Access rights ( security tab ) there we set domain users with the advanced settings to : Only this folder.
>
> So resulted in ( for windows ) user see only there folders, for linux users access to all user folders. Which i need for distributing file etc in user dirs.

I actually see a problem here, as we have linux member servers, where
users shouldn't be allowed to browse each others files. This linux
behavior gives me a real headache sometimes. Therefore I use
username:Domain Admins.

>
> For the profile path
> \\servername.domain.tld\profiles\%username%
> Here key is, user "SYSTEM" is use for creating the profiles folders.
> Which is the account the computer users and most importand that "SYSTEM" has all rights. ( and which exists on all windows computers )
> And the profile folder is created at Logoff, not like the users folder at klik OK/Apply.
> The "LOCAL PATH" is normaly ony used for terminal server.
>
> The Unix tab
> In this case.
> \\servername.domain.tld\users\%username%
> Which is /home/users/%username%
>
> Users is shared

What do you mean by that?

> And GID is set to "domain users"

Louis, do you always put the user in the "Unix Attributes" of the Domain
Users group? Probably that is necessary for group membership to work
correctly on linux, right? I just recently discovered this tab and was
wondering about it.

>
> So hope this is more clear...
>
> And i really advice to NOT user \\servername\home (or \homes )
> Why? You can set \\servername\%username% for the user home dir BUT no auto-created home dir.

That is not entirely true and applys to Rowlands last posting as well:
if you use 'root preexec' in the [homes] section, you can use scripted
auto-creation of user home share. I just successfully tried this and it
confirms my reading of the man pages that only if a share is requested
that is not actually existing, the [homes] section applies and 'root
preexec' there is executed (in case username exists and password is
correct).

However, I wouldn't want to use \\server\%username% as home dir
location, was well.

[L.P.H. van Belle]

Commented within...

> -----Oorspronkelijk bericht-----

> Van: samba [mailto:samba-...@lists.samba.org] Namens Ole Traupe

> Verzonden: donderdag 22 oktober 2015 11:13

> Aan: sa...@lists.samba.org
> Onderwerp: Re: [Samba] Can't get 'root preexec' to run
>

> Louis, I agree with you, with some exceptions:
>
> Am 22.10.2015 um 10:44 schrieb L.P.H. van Belle:
> > Hai, i'll try to explain so here..
> >
> > When you use ADUC console. This is what happens.
> >
> > ( for Profile tab in ADUC )
> >
> > The ADUC user creates the user network dir, but only what you set the
> > Drive letter: (connected with) \\servername.domain.tld\users\%username%
> > If you set the local pad, its not created.
> > This folder is created at the moment you clik OK, or Apply.
> >
> > For the profil folder, this is NOT created by the ADUC tool, but by the
> computer where the user is logging off. ( only created at logoff )
> > Normaly you set something like :
> > \\servername.domain.tld\profiles\%username%
> You probably mean 'logon', right?

[L.P.H. van Belle] No, profile folders are created at logoff.
Test is yourself, create a new user, set the homedir and profile path.
Login as the user, now goto the \\servername\profiles share,
And you see no folder of the newly created user. ;-)

>
> >
> > Users can access these shares.. but only see there own folders IF the
> share and folder rights are set correctly.
> >
> > For example. All my users have 770 on
> \\servername.domain.tld\users\%username%
> > Which gives in my case, username:Domain Users ( the unix primary group
> )
> >
> > The share rights tells that "everybody" has all rights.
> > ( you can change this to domain user for example, but i need everybody )
> >
> > The Access rights ( security tab ) there we set domain users with the
> advanced settings to : Only this folder.
> >
> > So resulted in ( for windows ) user see only there folders, for linux
> users access to all user folders. Which i need for distributing file etc
> in user dirs.
> I actually see a problem here, as we have linux member servers, where
> users shouldn't be allowed to browse each others files. This linux
> behavior gives me a real headache sometimes. Therefore I use
> username:Domain Admins.

[L.P.H. van Belle] thats a possebilty yes, but i suggest dont abuse the "Domain Admins" just create an other group set GID and use that one.
You will be even more flexible.

>
> >
> > For the profile path
> > \\servername.domain.tld\profiles\%username%
> > Here key is, user "SYSTEM" is use for creating the profiles folders.
> > Which is the account the computer users and most importand that "SYSTEM"
> has all rights. ( and which exists on all windows computers )
> > And the profile folder is created at Logoff, not like the users folder
> at klik OK/Apply.
> > The "LOCAL PATH" is normaly ony used for terminal server.
> >
> > The Unix tab
> > In this case.
> > \\servername.domain.tld\users\%username%
> > Which is /home/users/%username%
> >
> > Users is shared
> What do you mean by that?

[L.P.H. van Belle]

in ADUC tab Profile
\\servername.domain.tld\users\%username% = "connect to drive" + path

In ADUC tab Unix attributes.
/home/users/%username%
Which is the same as above. In profile tab.

>
> > And GID is set to "domain users"
> Louis, do you always put the user in the "Unix Attributes" of the Domain
> Users group? Probably that is necessary for group membership to work
> correctly on linux, right? I just recently discovered this tab and was
> wondering about it.

[L.P.H. van Belle]
Yes, in 90% of all case i use "domain users" why ..
All computer are member of "domain users"
All users are member of "domain users"
With share rights and security rights you protect the company folders.
Example.
\\servername\data
\Folder1
\Folder2

Group right on folder1 is "group users folder1 "
anyone member of folder 1 can write, set "group creating special right"
Now everyone in this folder can write but set to group rights = domain users. Result, no problems with file created by users, and users Owning files.

Same for folder 2.
BUT, users in "folder 1 group" can not access the Folder2, because of "GROUP Folder access"

I hope it explains a bit..

For the places where i need linux access, these user have there GID set to a group other then domain users. And or set creating special right and user special right.

Test a bit with it, and dont forget the share rights and security rights.

>
> >
> > So hope this is more clear...
> >
> > And i really advice to NOT user \\servername\home (or \homes )
> > Why? You can set \\servername\%username% for the user home dir BUT no
> auto-created home dir.
> That is not entirely true and applys to Rowlands last posting as well:
> if you use 'root preexec' in the [homes] section, you can use scripted
> auto-creation of user home share. I just successfully tried this and it
> confirms my reading of the man pages that only if a share is requested
> that is not actually existing, the [homes] section applies and 'root
> preexec' there is executed (in case username exists and password is
> correct).
>
> However, I wouldn't want to use \\server\%username% as home dir
> location, was well.
>

[L.P.H. van Belle] yes, Rowland is correct, if you dont use ADUC or if you dont create folders from within windows but im doing everything from windows, ( most people are ) and
no scripts etc run from linux or are set in samba.
I think it should not be needed, but this depends totaly on what you want and how you setup.

I do almost everything with group policies.
And 2 VB script for installing certificates.

[Ole Traupe]

Rowland, what are [homes] shares on a Unix machine?

What you describe seems to be mostly correct. However, in my eyes there
is no such thing as a collection of [homes] shares. This section gets
invoked whenever a non-existing share is requested. Thats what the man
pages say (with many complicated words) and what I just confirmed here.
It even works, if you put \\servername\%username% as home path in the
"Profiles" tab of the ADUC (applies right when you click ok).

Especially, if you are connecting from Windows to
\\servername\home\%username%, this path *is* honoured and Unix
Attributes don't come into play. Further, making this Windows way a bit
paradox or unsuited: if \\servername\home exists, the [homes] section
won't ever be used. So in my case, I can't create a zfs data set on an
existing share via 'root preexec', what really annoys me (maybe I put it
into the netlogon section). It would only apply, if the Samba server
'servername' is reachable and working correctly, but a [home] (without
s) share is nonexistent.

(Maybe this is different with different versions of Samba, I don't know.)

But, of course, you are right that on linux the file system has to be
mounted locally in order to access it. I sometimes forget to mention
Windows and Linux cases separately.

[Rowland Penny]

On 22/10/15 10:12, Ole Traupe wrote:
> Louis, I agree with you, with some exceptions:
>
> Am 22.10.2015 um 10:44 schrieb L.P.H. van Belle:
>> Hai, i'll try to explain so here..
>>
>> When you use ADUC console. This is what happens.
>>
>> ( for Profile tab in ADUC )
>>
>> The ADUC user creates the user network dir, but only what you set the
>> Drive letter: (connected with) \\servername.domain.tld\users\%username%
>> If you set the local pad, its not created.
>> This folder is created at the moment you clik OK, or Apply.
>>
>> For the profil folder, this is NOT created by the ADUC tool, but by
>> the computer where the user is logging off. ( only created at logoff )
>> Normaly you set something like :
>> \\servername.domain.tld\profiles\%username%
> You probably mean 'logon', right?

They have only been first created at logof for me.

>
>>
>> Users can access these shares.. but only see there own folders IF the
>> share and folder rights are set correctly.
>>
>> For example. All my users have 770 on
>> \\servername.domain.tld\users\%username%
>> Which gives in my case, username:Domain Users ( the unix primary
>> group )
>>
>> The share rights tells that "everybody" has all rights.
>> ( you can change this to domain user for example, but i need everybody )
>>
>> The Access rights ( security tab ) there we set domain users with the
>> advanced settings to : Only this folder.
>>
>> So resulted in ( for windows ) user see only there folders, for linux
>> users access to all user folders. Which i need for distributing file
>> etc in user dirs.
> I actually see a problem here, as we have linux member servers, where
> users shouldn't be allowed to browse each others files. This linux
> behavior gives me a real headache sometimes. Therefore I use
> username:Domain Admins.
>

Yes, you can do this.

>>
>> For the profile path
>> \\servername.domain.tld\profiles\%username%
>> Here key is, user "SYSTEM" is use for creating the profiles folders.
>> Which is the account the computer users and most importand that
>> "SYSTEM" has all rights. ( and which exists on all windows computers )
>> And the profile folder is created at Logoff, not like the users
>> folder at klik OK/Apply.
>> The "LOCAL PATH" is normaly ony used for terminal server.
>>
>> The Unix tab
>> In this case.
>> \\servername.domain.tld\users\%username%
>> Which is /home/users/%username%
>>
>> Users is shared
> What do you mean by that?

I think he means he has a share called 'Users' on the Samba machine.

>
>> And GID is set to "domain users"
> Louis, do you always put the user in the "Unix Attributes" of the
> Domain Users group? Probably that is necessary for group membership to
> work correctly on linux, right? I just recently discovered this tab
> and was wondering about it.

This is not required when using winbind, all users are members of the
windows group 'Domain Users' and it is their primary group. If you were
to examine the 'Domain Users' group object in AD, you would find that it
appears to have no members, but as I am sure you are aware all domain
users are a member of this group.

>
>>
>> So hope this is more clear...
>>
>> And i really advice to NOT user \\servername\home (or \homes )
>> Why? You can set \\servername\%username% for the user home dir BUT no
>> auto-created home dir.
> That is not entirely true and applys to Rowlands last posting as well:
> if you use 'root preexec' in the [homes] section, you can use scripted
> auto-creation of user home share. I just successfully tried this and
> it confirms my reading of the man pages that only if a share is
> requested that is not actually existing, the [homes] section applies
> and 'root preexec' there is executed (in case username exists and
> password is correct).
>

You are still confusing 'homeDirectory' for 'unixHomeDirectory', it is
the later that means anything on a Unix machine and it is the contents
of this attribute that will be used for the users Unix home path. This
directory will *not* be created at login to a Unix machine unless you
write your own script to do this, or use something like pam_mkhomedir on
debian.

> However, I wouldn't want to use \\server\%username% as home dir
> location, was well.
>
>

I wouldn't either, mostly because it wouldn't work.

Rowland

>>
>> And you dont want \\servername\username , for XP this was ok, because
>> of path traversal problems but as Win Vista/7 and up easely blok that.
>> (see above)
>>
>> Greetz
>>
>> Louis
>>
>>
>>
>>

[Ole Traupe]

The ADUC is very comfortable, and - even for the Samba devs, it seems -
the intended way of use. This whole stuff is mainly directed to Windows
use. But that is only my opinion.

[Rowland Penny]

On 22/10/15 10:38, Ole Traupe wrote:
> The ADUC is very comfortable, and - even for the Samba devs, it seems
> - the intended way of use. This whole stuff is mainly directed to
> Windows use. But that is only my opinion.
>

It is the only GUI way to admin a Samba 4 AD domain, but you can
(mostly) admin it from the command line using samba-tool.
You can do some things easier and quicker using samba-tool, i.e. create
a Unix user, one command and that is it, not create the user and then
have to open the users info, select 'Unix Attributes' tab, check and
alter the settings, then if you want to add an email address, you have
to go to another tab.

[Rowland Penny]

On 22/10/15 10:37, Ole Traupe wrote:
> Rowland, what are [homes] shares on a Unix machine?

It is described in the smb.conf manpage, but briefly if you try to
connect to a share called 'username' and samba knows nothing about a
share called 'username' it checks if there is a user called 'username'.
If this user exists, it obtains the users Unix homedir and uses this for
the share name and path. So if there is a user called 'username' and
there is a share called '[homes]' in smb.conf, then the users homedir is
obtained, on a DC this will be '/home/DOMAIN/username' unless 'template
homedir = ' is set to in smb.conf, on a domain member, winbind will use
the contents of the 'unixHomeDirectory' attribute, but this *must* be a
local path.

>
> What you describe seems to be mostly correct. However, in my eyes
> there is no such thing as a collection of [homes] shares. This section
> gets invoked whenever a non-existing share is requested. Thats what
> the man pages say (with many complicated words) and what I just
> confirmed here. It even works, if you put \\servername\%username% as
> home path in the "Profiles" tab of the ADUC (applies right when you
> click ok).

Profiles have *nothing* to do with home directories.

>
> Especially, if you are connecting from Windows to
> \\servername\home\%username%, this path *is* honoured and Unix
> Attributes don't come into play. Further, making this Windows way a
> bit paradox or unsuited: if \\servername\home exists, the [homes]
> section won't ever be used. So in my case, I can't create a zfs data
> set on an existing share via 'root preexec', what really annoys me
> (maybe I put it into the netlogon section). It would only apply, if
> the Samba server 'servername' is reachable and working correctly, but
> a [home] (without s) share is nonexistent.
>

If you are trying to connect from windows using the profile share, you
will need to use [profiles] not [homes] or [home], not sure if this will
work, because the profile (as far as I am aware) is written at first
logoff and then updated at each subsequent logoff.

> (Maybe this is different with different versions of Samba, I don't know.)

Nope, all recent versions of Samba have worked in this way.

Rowland

>
> But, of course, you are right that on linux the file system has to be
> mounted locally in order to access it. I sometimes forget to mention
> Windows and Linux cases separately.
>
>
>

[Ole Traupe]

Thanks, wasn't aware of that!

I meant "Users is shared", but Rowland already cleared this up (thanks!)

Louis, with which method and options (permissions also) do you make
"\\servername.domain.tld\users" accessible on domain member servers?

>
>
>>> And GID is set to "domain users"
>> Louis, do you always put the user in the "Unix Attributes" of the Domain
>> Users group? Probably that is necessary for group membership to work
>> correctly on linux, right? I just recently discovered this tab and was
>> wondering about it.
> [L.P.H. van Belle]
> Yes, in 90% of all case i use "domain users" why ..
> All computer are member of "domain users"
> All users are member of "domain users"
> With share rights and security rights you protect the company folders.
> Example.
> \\servername\data
> \Folder1
> \Folder2
>
> Group right on folder1 is "group users folder1 "
> anyone member of folder 1 can write, set "group creating special right"
> Now everyone in this folder can write but set to group rights = domain users. Result, no problems with file created by users, and users Owning files.
>
> Same for folder 2.
> BUT, users in "folder 1 group" can not access the Folder2, because of "GROUP Folder access"
>
> I hope it explains a bit..

Sorry, Louis, I appreciate the effort, but you lost me completely. Of
course, I use the Domain Users group. But is it necessary to fill it on
the Unix Attributes tab as well? That was the question, Rowland said 'no'.

Apart from that: With 'group right' you mean Unix permissions and not
Windows ACLs, right? Do you actually create AD user groups just for
managing access right to single particular folders?

[Rowland Penny]

On 22/10/15 11:10, Ole Traupe wrote:
> Ok, we have a different opinion on that. :)

>
>
> Am 22.10.2015 um 11:53 schrieb Rowland Penny:
>> On 22/10/15 10:38, Ole Traupe wrote:
>>> The ADUC is very comfortable, and - even for the Samba devs, it
>>> seems - the intended way of use. This whole stuff is mainly directed
>>> to Windows use. But that is only my opinion.
>>>
>>
>> It is the only GUI way to admin a Samba 4 AD domain, but you can
>> (mostly) admin it from the command line using samba-tool.
>> You can do some things easier and quicker using samba-tool, i.e.
>> create a Unix user, one command and that is it, not create the user
>> and then have to open the users info, select 'Unix Attributes' tab,
>> check and alter the settings, then if you want to add an email
>> address, you have to go to another tab.
>>
>> Rowland
>>
>>
>>
>
>

What would the world be, if we couldn't agree to disagree :-)

[Ole Traupe]

Ok, we have a different opinion on that. :)


Am 22.10.2015 um 11:53 schrieb Rowland Penny:

[Ole Traupe]

Am 22.10.2015 um 12:09 schrieb Rowland Penny:
> On 22/10/15 10:37, Ole Traupe wrote:
>> Rowland, what are [homes] shares on a Unix machine?
>
> It is described in the smb.conf manpage, but briefly if you try to
> connect to a share called 'username' and samba knows nothing about a
> share called 'username' it checks if there is a user called 'username'.

Rowland, you are stating *exactly* what I was repeating several times now!!

> If this user exists, it obtains the users Unix homedir and uses this
> for the share name and path. So if there is a user called 'username'
> and there is a share called '[homes]' in smb.conf, then the users
> homedir is obtained, on a DC this will be '/home/DOMAIN/username'
> unless 'template homedir = ' is set to in smb.conf, on a domain
> member, winbind will use the contents of the 'unixHomeDirectory'
> attribute, but this *must* be a local path.

Yes, I know.

>
>>
>> What you describe seems to be mostly correct. However, in my eyes
>> there is no such thing as a collection of [homes] shares. This
>> section gets invoked whenever a non-existing share is requested.
>> Thats what the man pages say (with many complicated words) and what I
>> just confirmed here. It even works, if you put
>> \\servername\%username% as home path in the "Profiles" tab of the
>> ADUC (applies right when you click ok).
>
> Profiles have *nothing* to do with home directories.

In know that! But in ADUC, the darn tab is just *named* that way! Go lok
it up!

[Rowland Penny]

That is not where you set the Unix home directory, yes there is a
heading called 'home folder' on the 'Profiles' tab, but you should be
using the 'Home directory' box on the 'UNIX Attributes' tab.

Rowland

[Rowland Penny]

A bit more info on this: 'home folder' on the Profiles tab sets the
'homeDirectory' attribute (windows) and 'Home Directory' on the UNIX
Attributes tab, sets the 'unixHomeDirectory' attribute (Unix)

[L.P.H. van Belle]

Commented within...

> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-...@lists.samba.org] Namens Ole Traupe

> Verzonden: donderdag 22 oktober 2015 12:09

[L.P.H. van Belle] this depends, i use nfs3 or nfs4 or cifs.
Based on my needs, aka where users login and not.
I have for example only 5 linux users, mostly on a different server then the users and company data.

> to a group other then domain users. And or set creating special right and
> user special right.

[L.P.H. van Belle] ok, i'll try in most simple terms per example
( a windows minded setup )
For a windows pc. you map a share, like drive K: ( \\servername\sharename )
A users wil see
K:\folder1 (windows group : Group_folder1 )
K:\folder2 (windows group : Group_folder2 )

Now if in ADUC you keep the GID on Domain Users.
Files in folder1 are created and get rights : username:"Domain Users"
Because of the "Group_folder" member ship (and same for folder2)
A user can access folder1 (or 2) only if they are group member.
And visa versa.

Now i have 1 user which is also a unix user. ( i assigned him a uid/gid )
BUT for my unix acl rights i need to set the primary group to the group the unix users need.

To make things more easy, i always set :
acl_xattr:ignore system acl = yes
on my shares. Windows ignores the rights for unix. But if i work from ssh.
The unix rights do apply, and in this case you need to set the corrrect GID on the "K:\Folder1"

So folder1 in linux, is for example, /home/samba/folder1
And has unix rights root:LinuxGroup
( and the "LinuxGroup" can be a windows group with GID)
And Windows ignores the linux rights, so windows users can access these files also.

Its a bit fiddeling around, testing until you get/set what you want.
And, this works for me, but maybe your environment does not apply for a setup like this.

Best is to read :
https://wiki.samba.org/index.php/Shares_with_Windows_ACLs

https://wiki.samba.org/index.php/User_home_drives
( only i change [home] for [users] so these things dont get mixed up. )
And on the User home drives link.. read the "On *nix"
The important part.
"This entry only appears, if you had assigned a UID in the „Unix Attributes“ tab before the home was created!"

Hope its bit more clear, i dont know how to better explain.. :-/

[mourik jan heupink]

On 10/22/2015 11:37 AM, Rowland Penny wrote:
>> However, I wouldn't want to use \\server\%username% as home dir
>> location, was well.
>>
>>
>
> I wouldn't either, mostly because it wouldn't work.
>
> Rowland

Well it has been working here for *many* years, pretty much already
since samba 2.2.8 days. The only problem is that nowadays (when using
AD/aduc) ADUC insists to create the folder for us, and that doesn't work
with \\server\%username%

(and yes, I know about the other ways to create users, it's just that
the persons creating our users like the regular windows tools to do
their job)

MJ

[Rowland Penny]

On 22/10/15 13:07, mourik jan heupink wrote:
>
>
> On 10/22/2015 11:37 AM, Rowland Penny wrote:
>>> However, I wouldn't want to use \\server\%username% as home dir
>>> location, was well.
>>>
>>>
>>
>> I wouldn't either, mostly because it wouldn't work.
>>
>> Rowland

Perhaps I should have been a bit more explicit, having a
'unixHomeDirectory' attribute containing '\\server\%username%' will not
work, it is expected to contain something like '/home/rowland' i.e. the
path to the home directory belonging to Rowland. Unix would not identify
backslashes, it expects forward slashes , it wouldn't be able to
understand '%username%' either

[Ole Traupe]

The next interesting question for me is:

If I put '\\server\%username%' into ADUC Windows part (or
\\server\username explicitly, for that matter), Samba on 'Ok/Apply'
registers the attempt to access a non-existing share and applies the
[homes] section (executes 'root preexec'). I tested that. However, the
user doing this is the domain admin. So Samba would look that user up
and create a new share named like the *domain admin* user - and link it
to the local home of the domain admin user (if not specified otherwise).
That is not what we want.

If I put '/home/user' into the ADUC Unix Attributes, and the user then
logs on to a domain member server, nothing will happen. Because the
share 'home' ([home] without s) already exists. Because it already has
to be mounted on the member server. Otherwise, the the user logging on
wouldn't be able to access it. And even if it did not exist: the user
always accesses locally mounted stuff, so never actually access the
Samba file server hosting the (intended) home shares

So how do you actually use this option?

The only solution I could come up with is a logon script mounting the
user's home on demand (on logon). But that would fail, because the user
has no root permissions. Right? Or am I missing something?

[Rowland Penny]

root preexec (S)

This is the same as the preexec parameter except that the
command
is run as root. This is useful for mounting filesystems (such as
CDROMs) when a connection is opened.

preexec (S)

This option specifies a command to be run whenever the
service is
connected to. It takes the usual substitutions.

[Rowland Penny]

On 22/10/15 14:35, Ole Traupe wrote:
> So you are suggesting to use the 'root preexec' parameter to try to
> map a non-existing share in order to have the Samba file server create
> it.
>
> This time, this 'root preexec' is in which smb.conf section on what
> server? My DC is not the server hosting the homes.
>
>
>

The title of this thread is: [Samba] Can't get 'root preexec' to run

You now seem to have got the share '[homes]' working but have found that
by using 'root preexec' your script is being run by the 'root' user. I
was just pointing out that there is another command called 'preexec' and
as an aside, just who did you think was going run a command run from
something called 'root preexec' ????

Rowland

[Ole Traupe]

No. You don't actually seem to reed what I am writing. I pointed out
that in the two scenarios I described before the [homes] section never
correctly comes into play.

Lets forget about the Windows part. ADUC is not creating the share as
the respective user and would just mess things up.

Lets focus on the Linux side instead. This [homes] section applies if
you try to access a share that doesn't exist - then that is created. But
on the other side, Unix users can only access something that is already
locally mounted - e.g. the home directory base folder (\\server\home
would it be addressed by Windows). So the user logging on to a domain
member server accesses something locally mounted to e.g. /home. So this
share already exists. Ergo, the [homes] section on the file server won't
come into play at all.

The only way this could work would be, if the user himself would mount
his personal share directly at logon. And this could be accomplished via
a logon script in the netlogon share OR a second 'root preexec' in the
[netlogon] section of smb.conf - both on the DC (the latter even
involving remote ssh mount commands executed on the domain member
server). But this seems awfully complicated to me and I wouldn't think
this is the intended use (which I am trying to figure out).

So I actually would like to ask one of the devs: how is this meant to be
used?