[Samba] bugged mount with Synology as client.

[Xen]

Hi,

I have some weird issue I don't know how to tackle.

When I share a folder from a Unix (Linux) machine using a current
version of Samba (smbd) and I mount it on an older Synology (2.6.32) the
reading of files goes fine.

However all files I create get the chacacters #EF80AF affixed to the
filename, which is a Unicode code point for private extensions, or
something of the kind.

Perhaps it also means "left-to-right", I don't know.

The CIFS kernel module might very well be modified by Synology, I don't
know.

Although modinfo just produces the following (without parms):

filename: /nas/home/cifs.ko
version: 1.61
description: VFS to access servers complying with the SNIA CIFS
Specification e.g. Samba and Windows
license: GPL
author: Steve French <***@us.ibm.com>
srcversion: BAD2BA742996F91AC9BA4E4
depends:
vermagic: 2.6.32.12 mod_unload ARMv5

From another current Linux machine (same kind, I guess) operation is
flawless, no problem whatsoever from what I can see.

Actually that #EF80AF is getting prefixed, not affixed, in that sense
that a filename may become (on the server):

00000000 ef 80 af 77 65 69 72 64 0a |...weird.|
00000009

(where the newline is just added by ls). So #ef80af is utf-8. There is
no other log output on the part of the server.

Unix extensions are in affect but in fact even .... I'm sorry, reading
stuff also doesn't work.

A regular file requested that was written by another host (and has
normal characters in the name) results in "File not found" when trying
to e.g. cat.

"No such file or directory."

Do I need to compile a new kernel module? I guess I'll start doing that
but it has to come from the 2.6.32 tree so it will be that same older
module probably.

So I just absolutely don't know what is going on. If you can help,
please.!.

[Xen]

I wrote here how my filenames are getting mangled when getting sent or
received to the server.

Server: current Ubuntu lookalike.

Client: Older Synology diskstation with probably a modified mount.cifs.

When I send utf-8 it gets received as dos.

"é" for instance is #c3a9 in utf-8, and it is used by the server as #c3,
#a9, two separate bytes, becoming é.

The server is just configured with defaults for "dos" and "unix"
clients.

The client tries to use iocharset=utf8.

What can I do to enforce utf8 being recognised by the server?

It apparently thinks it is talking to a dos client.

But unix extensions are being negotiated because the client sees the
permissions and ownership of the separate files.


Anyone know what to do? Do I need a different mount.cifs?

Regards.

[Xen]

Post by Xen
I wrote here how my filenames are getting mangled when getting sent
or received to the server.
Server: current Ubuntu lookalike.
Client: Older Synology diskstation with probably a modified
mount.cifs.
When I send utf-8 it gets received as dos.
"é" for instance is #c3a9 in utf-8, and it is used by the server as
#c3, #a9, two separate bytes, becoming é.
The server is just configured with defaults for "dos" and "unix"
clients.
The client tries to use iocharset=utf8.
What can I do to enforce utf8 being recognised by the server?

unix charset = utf8
in the [global] section of the synology smb.conf.

I did that.

I fixed it for now by copying what the web interface for the device does
(the client).

It uses the "nounix" option and this fixes the issue.

I had to create a shell script as wrapper to capture its options :p.

Actually I tried both "utf8" and "UTF-8" in the config section on the
server.

I am sorry if I hadn't made that clear, I had thrown away all of the log
output I had pasted in my email.


I recompiled mount.cifs from source but this didn't make a difference.
However compiling all of samba is near impossible due to all the missing
libraries on that system.

(Even getting libwbclient proves to be quite a hassle).

This is the full line the device uses:

-o
soft,user=WORKGROUP\guest,pass=,iocharset=utf8,uid=1024,gid=100,nounix,file_mode=0777,dir_mode=0777,nocase

But only "nounix" was necessary here in this sense. However this
apparently disables unix-extensions and so I do not see any longer the
ownership of files now.

So basically with unix-extensions disabled, utf8 conversion fails to
work???

[Xen]

With unix extensions disabled, I think the cifsfs client
does the private character area mapping to be able to
store ':' and other banned characters.

The issue was not special characters in the first place.

With extensions enabled, what happened was this:

the server received every filename as:

2F F0 65 00

where 65 00 would for example be the first letter of the timename (like
's' or something) and 2F F0 would be a preceding character.

This is little-endian notation. Apparently this is the buffer received
by the server.

So it gets read as #F02F which is a unicode code point that translates
to #ef80af in utf-8 on disk. So the file created by the client called
"some_file" becomes

"^some_file" where ^ is the special character resulting from that utf8
character.

Equally, when reading files, the client apparent sends a request that
gets received as that same. Consequently If I send a request for
"some_file" the server receives it as a request for "^some_file" and
cannot find the file requested.

I don't have the log right now. It is on another computer and I have a
hard time walking.

But in the log with verbosity 10 you can see a buffer dump as above with
little-ending 16-bit values and each time there will be that 2F F0
preceding the actual filename.


At that point I started using special characters to see what would
happen and found that multi-byte utf-8 was getting interpreted as
individual unicode values (16-bit) by the server.

This doensn't happen on output *from* the server; ie. a directory
listing is actually correct. Done by the client. However filenames
requested or used by the client get mangled.

[Xen]

I want to ask what is the most common approach, and most functional
smallest-subset-technology approach to achieving the following.


- a samba server is using different users for its clients and these
users are general unix users, owning files and whatnot on the fs.

- a linux system as client now wants to "import" the users from the
server without making them /fixed/ unix/passwd users on the local system

- the users need to be imported from a kind of directory service (ldap
or whatever) or perhaps "active directory" or whatever it might be, and
those extra virtual users are only valid for as long as the samba shares
themselves are valid and accessible.

Mind you, I know nothing about "active directory" or "domain
controllers" or what it might be. I also have very little understanding
of what "nsswitch" is and the documentation for it and the entire system
itself seems to be rather arcane.

It would require on the client:
- an additional source of local users that cannot actually be logged in
to, but only serve as user interface elements.
Perhaps these local users would need to be mapped onto random numbers or
something, but normally with unix extensions you see the raw numbers of
the users on the central system (server).

So either those numbers would need to be replaced by ***@domain while
crossing the link and then mapped back to new numbers on the local
system, that has imported the ***@domain, or you'd need to find a
fixed "range" of numbers for users that can stay fixed from system to
system.

I haven't even been able to get idmapping to work for NFS, it just won't
work. I was using a "static" file for that but the thing would never
read the static maps.

It would require on the server:

- a set of local users transformed into a directory service that clients
can import or know about.


Is this possible and what technologies would I need for it?

[mathias dufresne]

Hi,

Let me try to re-formulate, please tell me if I'm wrong.

You have a bunch of users declared locally in /etc/passwd or something like
that on one system.

Now you would like to have another system using this users list with Samba.
You also want these users to be valid only as long as the share exist.
You don't want these users to be able to connect on system(s).

If I'm right, that sounds possible and not too complex to achieve, with a
minimum knowledge of UNIX systems. We can discuss about that once I know if
my understanding of your request was good enough ;)

Cheers,

mathias

Post by Xen
I want to ask what is the most common approach, and most functional
smallest-subset-technology approach to achieving the following.
- a samba server is using different users for its clients and these users
are general unix users, owning files and whatnot on the fs.
- a linux system as client now wants to "import" the users from the server
without making them /fixed/ unix/passwd users on the local system
- the users need to be imported from a kind of directory service (ldap or
whatever) or perhaps "active directory" or whatever it might be, and those
extra virtual users are only valid for as long as the samba shares
themselves are valid and accessible.
Mind you, I know nothing about "active directory" or "domain controllers"
or what it might be. I also have very little understanding of what
"nsswitch" is and the documentation for it and the entire system itself
seems to be rather arcane.
- an additional source of local users that cannot actually be logged in
to, but only serve as user interface elements.
Perhaps these local users would need to be mapped onto random numbers or
something, but normally with unix extensions you see the raw numbers of the
users on the central system (server).
crossing the link and then mapped back to new numbers on the local system,
of numbers for users that can stay fixed from system to system.
I haven't even been able to get idmapping to work for NFS, it just won't
work. I was using a "static" file for that but the thing would never read
the static maps.
- a set of local users transformed into a directory service that clients
can import or know about.
Is this possible and what technologies would I need for it?
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba

[Xen]

Post by mathias dufresne
Hi,
Let me try to re-formulate, please tell me if I'm wrong.
You have a bunch of users declared locally in /etc/passwd or something
like that on one system.
Now you would like to have another system using this users list with Samba.
You also want these users to be valid only as long as the share exist.
You don't want these users to be able to connect on system(s).
If I'm right, that sounds possible and not too complex to achieve,
with a minimum knowledge of UNIX systems. We can discuss about that
once I know if my understanding of your request was good enough ;)

Hi Mathias,

your summary is correct.

At this point I activated some LDAP server on the device, that my local
host(s) can now use to read users and group IDs so they are capable of
"showing a username/groupname" for IDs that are not in /etc/passwd,
since the samba mount does not do any mapping.

I just installed libnss-ldap, but not even libpam-ldap. All that was
necessary was to configure /etc/ldap.conf and /etc/nsswitch.conf and it
was already working.

The users on the local hosts are not getting prefixed with @domain.tld
as they are on that server in its default config, so it also shows up
pretty nicely in the shell (not sure what GUI actually shows user ids).

But I have to duplicate my users onto LDAP for that. In fact, at this
point those new users are only used for some uid/gid mount from other
systems.

What happens currently is that some user, e.g. john, connects through
the regular user account to the server, and the server is aware of this
(VPN). That user ID is then used to construct an LDAP user ID of the
same name, and this is then used to mount a share FROM that user to the
server. Not as a login credential (that is just guest) but as a
uid=/gid= designation.

This is because as I said in my other post, the mount.cifs won't
actually work with unix option. Mounts from the client to the server can
use unix just fine, but mounts from the server to clients have to use
nounix.

So the mounts from the clients (I mean the mounts shared by the clients
now) I can only mount using no-unix-extensions and uid=/gid=, which
means I have to give them a defined user. Since I have to do that
anyway, I am currently giving them LDAP users since those definitely
won't exist on the other clients.

So the shares originating from the server that DO use unix extensions
now have LDAP users attached to all of the files.

This in turn is resolved by the clients using LDAP in
/etc/nsswitch.conf. The only thing I haven't been able to do yet is:

- meaningfully add my local user (main user) to one of those groups such
that he obtains write permission on some of the files.

See, since there is no idMapping going on, all the files now have alien
specs and only root can write them.

That is not determined by the server (samba) but simply by the unix
permissions on my local host.

The only way to fix that is to force uid, but I don't want that or I
lose the information of file ownership.

However I also don't want to add my user to every group. The problem I
have is that unix does not support groups within groups, ie. there is no
group hierarchy.

Let's say I am a toad and I want write access to the frogs group. But I
don't want to become member of frogs myself; I don't want to become a
frog. How can I have write access locally?

The only thing I know what to do is using setfacl, but the server
resists that.

Besides, it would have no bearing on the local system unless they were
posix acl lists that were transmitted back. On the server I can create
finegrained permissions but they are not transmitted ... actually they
are, based on my logged in user.

If my user on the server is part of group "backup" and I set permissions
for backup:

synoacltool -add hoho group:backup:allow:rwx:fd--

Then even though the group owner for file "hoho" is something else, I
now get personalized "other" flags since my user is neither owner nor in
the main group, and my local permissions become:

-------rw- 1 1031 65538 21 jul 12 21:16 hoho

Of course this means every user on my system will have write access
unless I block access to the directory.

The server doesn't have pam_group and pam_exec so I may need to compile
both.

There is no way for me to add local users to the LDAP groups.

Then order to have those permissions I need to create an equivalent LDAP
user and log into samba using that.

However when I do so it gives preference to the local user and
disregards the LDAP suffix. But when I add the LDAP suffix as the
domain, it does work.

And that works. I log in as the LDAP user on samba instead of local user
on samba system, and my local user now has:

-------rwx 1 1031 65538 21 jul 12 21:16 hoho

Except that it doesn't work. Locally even though it says rwx for "other"
I cannot even open the file; apparently denied by the server. On the
server this same user however does have the appropriate rights.

Whereas the non-LDAP user doesn't (as per design).

So the appropriate permissions are now transferred to the client, but
they don't take affect when trying to be used.

At least; not for this particular file. Permissions work fine without
these "custom" Synology ACLs, but then there is no way to add a group to
a group.

I have no clue why I would be able to write on the filesystem but not to
samba.

That when Samba writes on my behalve, it is denied.

I guess it checks permissions before becoming my user to see it though
my eyes? These Syno ACLS are shifty. Hmm..


** my current problem is that samba denies me write access to a file I
have write access to on a share I have write access to **.

My second problem is a Linux/Unix thing. Which is that I need to add
myself to every group, to have write access to every file. I might just
as well give them 777 and then defend the access paths instead, and be
done with it. I am just worried there is no good way to prevent deletion
by random users, but I'll just the sticky bit for that.

Unix permissions are just about as primitive as coming up with a fork
with 3 prongs and then thinking you've created a masterful design no one
can beat.

And the most obvious thing: hierarchy, doesn't even exist.

But then, the group is hardly used in the Unix world. 99% of file are
owned by root:root, you may say that the Unix model is to have root and
a general no-permission user, and nothing else.

The only things that ever have dedicated users/groups are daemons and
services, that do so to have reduced capability during normal operation
(but that are started as root regardless). And there are a few files in
/dev, that's about it.

The state of affairs is so primitive that every good idea needs a vast
amount of time to really develop. And in the end most successful designs
do not even impede on the Linux model, but create their own user
databases and interaction because they focus on web-services and the
like. The solution to the Unix permissions is to not use it ;-).






So currently for me:

- I can use "factory default" LDAP to manually create a copy of each
user
- I now have "virtual" users I use only to map samba shares to (by way
of uid/gid)
- My server won't function as a client with unix extensions enabled,
even to unix servers (samba).
- The virtual users can be imported on the clients by way of LDAP and
for no other reason than to give names to numbers
- I installed nscd because LDAP lookup was really slow, and unreliable
really.
- Everything I export from the server I will need to do with virtual
users so that they are correctly displayed on the clients
- Client GUIs do not even really display any user:group information.

- Giving detailed enough permissions to public shares and public files,
is a challenge. It's easy to make everything read-only for most. It is
harder to give people upload permission but not modify or delete
permission. (Well covered in [1]). But there is not really a solution
other than the sticky bit.

But mostly hierarchical groups are missing from Unix. It would be
extremely trivial to implement too.

I think I can work with what I have now. It's a shame the Synology ACLs
do not actually work with this Linux client (when accessed through
Samba).

I wonder why that is. I wonder if Samba /cannot write/ or /thinks it
cannot write/ (or read).






[1]
https://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/AccessControls.html).

[mathias dufresne]

I haven't yet fully read your mail, still trying to understand.

Anyway all that I read is about complexity of using several users
databases. Why not use only one user database? AD is a user database, can
be used on all these systems, can be used in conjunction with Samba... All
user names, UIDs and GIDs would be into the same DB, they would be coherent
(if you don't mess up your DB obviously ^^) and that could simplify
stuffs...

The only things which could be an issue is about clients behind a VPN (you
mentioned that techno at some point).
If this VPN is about to merge some networks, if it is permanent, these
clients would be able to access permanently AD DC and all things are easy.
If this VPN is multiple and started by each and every client randomly (e.g:
VPN for laptops accessing company's LAN from home) and these clients are
joined to AD, they will have to use credentials caching mechanism, which is
including in most of tools (from Linux or Windows) to connect on AD
domains, so there should be not too much difficulty to also have VPN
clients joined to your AD.

Now if clients are from different companies and have already one (by
company) dedicated domain, you will have an issue: you start with a real
need to deal with all these user sources...

Once user DB sources issue would be simplified you will have only to manage
others points:
- users can't connect on certain systems -> dealing with user's shell
(/bin/false, [/usr]/sbin/nologin..) or with access module
(/etc/security/access.conf)
- users are valid only as long as their shares are existing -> some script
to activate / deactivate them from AD when share is removed would do.
Whatever is the way you chose to deactivate them.

That was just morning's idea, back to read.

Post by Xen

Post by mathias dufresne
Hi,
Let me try to re-formulate, please tell me if I'm wrong.
You have a bunch of users declared locally in /etc/passwd or something
like that on one system.
Now you would like to have another system using this users list with Samba.
You also want these users to be valid only as long as the share exist.
You don't want these users to be able to connect on system(s).
If I'm right, that sounds possible and not too complex to achieve,
with a minimum knowledge of UNIX systems. We can discuss about that
once I know if my understanding of your request was good enough ;)

Hi Mathias,
your summary is correct.
At this point I activated some LDAP server on the device, that my local
host(s) can now use to read users and group IDs so they are capable of
"showing a username/groupname" for IDs that are not in /etc/passwd, since
the samba mount does not do any mapping.
I just installed libnss-ldap, but not even libpam-ldap. All that was
necessary was to configure /etc/ldap.conf and /etc/nsswitch.conf and it was
already working.
they are on that server in its default config, so it also shows up pretty
nicely in the shell (not sure what GUI actually shows user ids).
But I have to duplicate my users onto LDAP for that. In fact, at this
point those new users are only used for some uid/gid mount from other
systems.
What happens currently is that some user, e.g. john, connects through the
regular user account to the server, and the server is aware of this (VPN).
That user ID is then used to construct an LDAP user ID of the same name,
and this is then used to mount a share FROM that user to the server. Not as
a login credential (that is just guest) but as a uid=/gid= designation.
This is because as I said in my other post, the mount.cifs won't actually
work with unix option. Mounts from the client to the server can use unix
just fine, but mounts from the server to clients have to use nounix.
So the mounts from the clients (I mean the mounts shared by the clients
now) I can only mount using no-unix-extensions and uid=/gid=, which means I
have to give them a defined user. Since I have to do that anyway, I am
currently giving them LDAP users since those definitely won't exist on the
other clients.
So the shares originating from the server that DO use unix extensions now
have LDAP users attached to all of the files.
This in turn is resolved by the clients using LDAP in /etc/nsswitch.conf.
- meaningfully add my local user (main user) to one of those groups such
that he obtains write permission on some of the files.
See, since there is no idMapping going on, all the files now have alien
specs and only root can write them.
That is not determined by the server (samba) but simply by the unix
permissions on my local host.
The only way to fix that is to force uid, but I don't want that or I lose
the information of file ownership.
However I also don't want to add my user to every group. The problem I
have is that unix does not support groups within groups, ie. there is no
group hierarchy.
Let's say I am a toad and I want write access to the frogs group. But I
don't want to become member of frogs myself; I don't want to become a frog.
How can I have write access locally?
The only thing I know what to do is using setfacl, but the server resists
that.
Besides, it would have no bearing on the local system unless they were
posix acl lists that were transmitted back. On the server I can create
finegrained permissions but they are not transmitted ... actually they are,
based on my logged in user.
If my user on the server is part of group "backup" and I set permissions
synoacltool -add hoho group:backup:allow:rwx:fd--
Then even though the group owner for file "hoho" is something else, I now
get personalized "other" flags since my user is neither owner nor in the
-------rw- 1 1031 65538 21 jul 12 21:16 hoho
Of course this means every user on my system will have write access unless
I block access to the directory.
The server doesn't have pam_group and pam_exec so I may need to compile
both.
There is no way for me to add local users to the LDAP groups.
Then order to have those permissions I need to create an equivalent LDAP
user and log into samba using that.
However when I do so it gives preference to the local user and disregards
the LDAP suffix. But when I add the LDAP suffix as the domain, it does work.
And that works. I log in as the LDAP user on samba instead of local user
-------rwx 1 1031 65538 21 jul 12 21:16 hoho
Except that it doesn't work. Locally even though it says rwx for "other" I
cannot even open the file; apparently denied by the server. On the server
this same user however does have the appropriate rights.
Whereas the non-LDAP user doesn't (as per design).
So the appropriate permissions are now transferred to the client, but they
don't take affect when trying to be used.
At least; not for this particular file. Permissions work fine without
these "custom" Synology ACLs, but then there is no way to add a group to a
group.
I have no clue why I would be able to write on the filesystem but not to
samba.
That when Samba writes on my behalve, it is denied.
I guess it checks permissions before becoming my user to see it though my
eyes? These Syno ACLS are shifty. Hmm..
** my current problem is that samba denies me write access to a file I
have write access to on a share I have write access to **.
My second problem is a Linux/Unix thing. Which is that I need to add
myself to every group, to have write access to every file. I might just as
well give them 777 and then defend the access paths instead, and be done
with it. I am just worried there is no good way to prevent deletion by
random users, but I'll just the sticky bit for that.
Unix permissions are just about as primitive as coming up with a fork with
3 prongs and then thinking you've created a masterful design no one can
beat.
And the most obvious thing: hierarchy, doesn't even exist.
But then, the group is hardly used in the Unix world. 99% of file are
owned by root:root, you may say that the Unix model is to have root and a
general no-permission user, and nothing else.
The only things that ever have dedicated users/groups are daemons and
services, that do so to have reduced capability during normal operation
(but that are started as root regardless). And there are a few files in
/dev, that's about it.
The state of affairs is so primitive that every good idea needs a vast
amount of time to really develop. And in the end most successful designs do
not even impede on the Linux model, but create their own user databases and
interaction because they focus on web-services and the like. The solution
to the Unix permissions is to not use it ;-).
- I can use "factory default" LDAP to manually create a copy of each user
- I now have "virtual" users I use only to map samba shares to (by way of
uid/gid)
- My server won't function as a client with unix extensions enabled, even
to unix servers (samba).
- The virtual users can be imported on the clients by way of LDAP and for
no other reason than to give names to numbers
- I installed nscd because LDAP lookup was really slow, and unreliable
really.
- Everything I export from the server I will need to do with virtual users
so that they are correctly displayed on the clients
- Client GUIs do not even really display any user:group information.
- Giving detailed enough permissions to public shares and public files, is
a challenge. It's easy to make everything read-only for most. It is harder
to give people upload permission but not modify or delete permission.
(Well covered in [1]). But there is not really a solution other than the
sticky bit.
But mostly hierarchical groups are missing from Unix. It would be
extremely trivial to implement too.
I think I can work with what I have now. It's a shame the Synology ACLs do
not actually work with this Linux client (when accessed through Samba).
I wonder why that is. I wonder if Samba /cannot write/ or /thinks it
cannot write/ (or read).
[1]
https://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/AccessControls.html
).

[Xen]

Post by mathias dufresne
I haven't yet fully read your mail, still trying to understand.
Anyway all that I read is about complexity of using several users
databases. Why not use only one user database? AD is a user database,
can be used on all these systems, can be used in conjunction with
Samba... All user names, UIDs and GIDs would be into the same DB, they
would be coherent (if you don't mess up your DB obviously ^^) and that
could simplify stuffs...

AD is much more complex than what I want to get into..

Also these are Linux to Linux systems currently.

It would be possible to only use LDAP users but not very convenient.

The real setup I want, the only issue is how to merge deal with local
accounts vs. ldap accounts. I cannot get them on LDAP totally as you say
because they only have access to LDAP when using VPN.

Suppose they have shares of their own (not just centrally, but
decentrally). Suppose other users of the VPN would be able to write to
their shares when connected. Now those writes would be done using LDAP
users. But the local computer doesn't have LDAP users when not
connected.

That is problematic by itself, hmm....

Maybe I already have the best I can achieve. I cannot expect the local
system to have users for whatever LDAP clients there might be. You could
imagine localizing the file ownership upon write; adding local users as
needed, and mapping their names to LDAP names when requested from the
VPN, that's a way to do it. Rather much development though.

I think I already have a rather stable solution at present, thank you
for your help.

I wrote here before that from my Linux client, the ACL on the server was
not honoured; I could not write locally even though I had rights
centrally.

Turns out it was a Linux bug, in the kernel, I just had to reboot and it
was fixed, apparently.

Linux suffers a lot from "stale handles" and "refcounts" that go wrong.

Often the only way to fix it is to reboot.

I have started using "noperm" locally to mount with unix extensions, so
that my local system doesn't bug me about being in the wrong group.

It is possible to add myself to LDAP groups (/etc/security/group.conf)
but that is semantically not correct for me; to achieve local access by
adding myself to some group, while the remote server has no problem with
my credentials.

On my Synology NAS posix ACLs are not transmitted to the Linux client.
It is not using posix ACLs I think.

And it also doesn't map them to it, I'm afraid.

[mathias dufresne]

Post by Xen
I want to ask what is the most common approach, and most functional
smallest-subset-technology approach to achieving the following.
- a samba server is using different users for its clients and these
users are general unix users, owning files and whatnot on the fs.
- a linux system as client now wants to "import" the users from the
server without making them /fixed/ unix/passwd users on the local system
- the users need to be imported from a kind of directory service
(ldap or whatever) or perhaps "active directory" or whatever it
might be, and those extra virtual users are only valid for as long
as the samba shares themselves are valid and accessible.
Mind you, I know nothing about "active directory" or "domain
controllers" or what it might be. I also have very little
understanding of what "nsswitch" is and the documentation for it and
the entire system itself seems to be rather arcane.
- an additional source of local users that cannot actually be logged
in to, but only serve as user interface elements.
Perhaps these local users would need to be mapped onto random
numbers or something, but normally with unix extensions you see the
raw numbers of the users on the central system (server).
while crossing the link and then mapped back to new numbers on the
find a fixed "range" of numbers for users that can stay fixed from
system to system.
I haven't even been able to get idmapping to work for NFS, it just
won't work. I was using a "static" file for that but the thing would
never read the static maps.
- a set of local users transformed into a directory service that
clients can import or know about.
Is this possible and what technologies would I need for it?

This sounds like NIS/YP to me :-). But I'm old... :-).

AD is somehow now meant also to replace them and that's fortunate :p

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

[Xen]

Post by Xen
I want to ask what is the most common approach, and most functional
smallest-subset-technology approach to achieving the following.
- a samba server is using different users for its clients and these
users are general unix users, owning files and whatnot on the fs.
- a linux system as client now wants to "import" the users from the
server without making them /fixed/ unix/passwd users on the local system
- the users need to be imported from a kind of directory service
(ldap or whatever) or perhaps "active directory" or whatever it
might be, and those extra virtual users are only valid for as long
as the samba shares themselves are valid and accessible.
Mind you, I know nothing about "active directory" or "domain
controllers" or what it might be. I also have very little
understanding of what "nsswitch" is and the documentation for it and
the entire system itself seems to be rather arcane.
- an additional source of local users that cannot actually be logged
in to, but only serve as user interface elements.
Perhaps these local users would need to be mapped onto random
numbers or something, but normally with unix extensions you see the
raw numbers of the users on the central system (server).
while crossing the link and then mapped back to new numbers on the
find a fixed "range" of numbers for users that can stay fixed from
system to system.
I haven't even been able to get idmapping to work for NFS, it just
won't work. I was using a "static" file for that but the thing would
never read the static maps.
- a set of local users transformed into a directory service that
clients can import or know about.
Is this possible and what technologies would I need for it?

This sounds like NIS/YP to me :-). But I'm old... :-).

The Synology has 3-second total-configuration for it ;-).

You click "Install Directory Server" and you select a few options and it
installs OpenLDAP.

The thing comes prepopulated or generated with Samba entities,
apparently. Then you go to Directory Service in the configuration
screen, and enter your connection details; actually it offers to do this
automatically. Then you select "Enable LDAP for CIFS" and it will modify
smb.conf with a new authentication line.

At that point LDAP users are shown as ***@FQDN in the shell.

They don't mingle with regular users but you can set permissions for
them the way you can for regular users and groups.

And when you change the FQDN it deletes all users and groups :p.

And it uses a different style user home directory for it. So it is not
as pretty. And if you don't care... well...

Apparently you can select which user you want (with Samba logon) by
setting the domain to that FQDN you've chosen.

So I have no clue how to actually export local users, but it is not that
necessary (and gives its own problems, I guess).

The only downside is that I have to manually duplicate users and groups,
but I guess that's pretty manageable given the size of my system ;-).

And when I can get pam_exec and pam_group installed, maybe more is
possible.

[Xen]

What you seem to be describing is a 'workgroup', the great-grandfather
of AD :-)
If you only have a few computers that are close together, then yes, it
probably will do what you require. If you have a lot of computers (and
by this I mean more than about 12), it becomes a nightmare, every new
user has to be added to every computer, then added to the required
groups. This soon became apparent to MS, who then came up with the NT4
style PDC, this then lead to AD. You do not need to have windows
computers to use AD, you can use it with Unix computers and it will
give you just one place of administration, you just need to set Samba
up correctly, for this, see the Samba wiki.

I know. But this is a disconnected system; I require users on the local
system for all the files on the local system.

In a sense the situation is this:

- all files that have central ownership and require central directory to
know about their owners, should not be on the local computer
- all files that do not have central ownership, can be on the local
computer.

By the way, I meant that I duplicate the users with LDAP on the server,
not on the local computers.

So I have two distinct sets of users: local and central. It's just that
I prefer local for SSH login (on the server).

I mean regular unix users instead of just LDAP users. One reason is
obviously that my Synology puts the home directory of LDAP users in
"/volume1/home/@LH-DISKSTATION.LOCAL/61/<username>" or something of the
kind.

That also implies that if I want to use regular home directories (the
//server/home share) I must not currently use LDAP users for it.
Moreover...

If I intend to have a public share that is likened to those of the other
shares with regular users, and if I want this public share to "hardlink"
some files from other shares, then the users are getting mixed.

But not doing that is troublesome because then my SSH user etc. won't be
able to create files that are readable by others. So now the regular
"public" share really requires a local (unix) user on the server, (not
on the client) whereas the shares that actually do have other users
contributing stuff will need LDAP users.

It's not all that pretty but.... it works for now. The issue is only
duplicating local users into LDAP or vice versa (for the server, not the
clients).

That is not something that would be hard to automate, in essence.


Meaning

//server/public ---> really requires local users on the server
//server/hub ---> really requires LDAP users on the server

Thus

//server/public <--- login with unix user
//server/hub <--- login with LDAP user

And it works.

//server/public ---> don't allow ownership information to reach the
client (use nounix)
//server/hub ---> do allow ownership information to reach the
client.

This way no local user on the server (unix users) will ever have any
impact on the client systems apart from the fact that they need 2 sets
of credentials files (or a domain flag for the hub login).

The credentials are the same, the /public login just doesn't require a
"domain" whereas the hub login does (to specify LDAP users).

This works with Samba as default the way it is installed :). It was a
pleasant surprise to find that using a domain instantly caused it to use
LDAP for authentication.


I have only one issue now on the clients.

When LDAP is live, and when switching users, they will see all the LDAP
users as well (passwd database) but they cannot login to it (auth
database).

LDAP users should not be allowed to login to local systems really. I do
not know yet of a way to filter this.

Maybe set a login shell variable in the LDAP?

http://www.tldp.org/HOWTO/archived/LDAP-Implementation-HOWTO/schemas.html

PosixAccount doesn't really specify a shell. Well, actually there is a
loginShell value in the LDAP database.

And putting it to /bin/false indeed prevents the account from being
listed :).

Now that I think about it, perhaps having an admin account on the system
would be in order.

Of course I can enable the root user.

Regardless this is not a user friendly thing and not meant for login.
Although at the same time, it is also not possible to have some Admin
user with Root rights.

The only thing you could possibly do is remove the regular user from
sudo access, but that is also not very convenient, seeing the number of
times you actually do need root access, even as a regular user.

It is not really acceptable to not be able to install packages, or
change simple things. Again, the root/user dichotomy in Linux bites me.

The user can do so little and the root can do so much that the user
needs to be root most of the time for doing anything. Stuff like the
"staff" group is hardly used on default linux systems, or at all.

At most you can grant a non-privileged user access to /usr/local, and
that's about it.

There is no per-user package install system or anything of the kind,
although Java applications usually go that route.

More work. Always more work ;-). The system is so bad, that everything
requires More Work.

Anyway, thank you for your attention ;-).

And putting me to work like this :(. But at least the fake login problem
is now solved, for now.

I just want a second user with Admin rights though. But I can only
create a duplicate of the current user in terms of access rights. "Root"
is not a user friendly nomenclature. We'd need a root user that is
called Admin ;-).

But this is hardly possible. Not unless I apply one big long ACL to all
of the files in the system.

recursively add u:admin:rwx to all of the files in the system. Then add
inherit rights as well.