Can't connect to samba...

Hi,

I have installed a samba server on a very old laptop, the smb4.conf is something like this

Code:
[global]
workgroup = workgroup
realm = realm
netibios name = netbios

[netbios]
path = mypath
public = no
printable = no
writable = yes
guestok = no
valid users = myuser

I have logged into another FreeBSD machine (where I have a different samba server installed but I don't know if this is the root the problem) and throughout the console, just after the login as root I write the following command:

mount_smbfs -I 192.168.1.123 //myuser@netbios/ /mnt
and I get the message
Code:
mount_smbfs: empty share name

then I try something else like

mount_smbfs -I 192.168.1.123 //myuser@netbios/mypath/ /mnt
or instead of the folder "mypath" I put the name of the folder I know it's inside the shared folder like mount_smbfs -I 192.168.1.123 //myuser@netbios/folder_name/ /mnt
and I get the message
Code:
mount_smbfs: unable to open connection: syserr = Operation timed out

then if u try it again I get the message
Code:
smb_smb_negotiate: Dono't know how to talk with serve xxx (65535)
mount_smbfs: unable to open connection: syserr = RPC struct is bad

I really have no idea how to fix this. Can you help me?

p.s. I have also tried to stop the server in the client computer with service samba_server stop but I guess it wasn't that because i get the same message :\
 
don't you have to set server min protocol in smb4.conf then ?
Yes, SMBv1 is disabled by default nowadays.
Code:
   client min protocol = NT1
   server min protocol = NT1
   ntlm auth = ntlmv1-permitted

Take note however, SMBv1 is horrendously insecure and has been disabled for good reason.
 
Stop right here. Regarding SMBv1, we should really pretend it doesn't exist. In my personal opinion, https://reviews.freebsd.org/D32707 should have been accepted...

I keep hearing rumors about plans to finally implement newer SMB versions in FreeBSD. That would be very nice. But until it is done, the take-away should be FreeBSD does not support the SMB file system (of course you can still run samba, providing a fully functional SMB server). For the time being, the only network file system usable on a FreeBSD client is NFS. Make it NFSv4 with kerberos to get decent security.

My file server (in a jail) offers both btw, Windows clients use SMB, all others NFS (to access the "same" shares).
 
Had to enable SMBv1 so I could share a CD image though IPMI to reinstall it remotely, old system, old IPMI, does not support anything other than SMBv1. But the Samba server is turned off and only enabled when needed.
 
as long as you know when you're playing with fire and how to control it ... ?

But yeah, don't do that at home in production.
 
thanks to all of you. I really mean it.

The lessons I take with me today is:
1. I should stop pretending to know what i'm doing :) keep the samba server online but access only with windows/tablets/tv etc...
2. I should start digging online on how to set up the NFS on the server

Considering that i have put the server in a very unconfortable place because i thought i could connect far away from the confort of my living room i sadly have to skip the idea to turn smb1 on and off (though that would have been exactly what i had in mind if the pc was close to me).
 
Yeah, don't open Samba (or NFS) to the internet, regardless of the authentication used. If you want to have a safer option to share files with SMB or NFS remotely consider using a VPN to connect to the remote server. Or, in many cases, a 'simple' scp(1) or sftp(1) will do. You could also do rsync(1) over ssh(1).
 
Yeah, don't open Samba (or NFS) to the internet, regardless of the authentication used. If you want to have a safer option to share files with SMB or NFS remotely consider using a VPN to connect to the remote server. Or, in many cases, a 'simple' scp(1) or sftp(1) will do. You could also do rsync(1) over ssh(1).
i don't even know how to do that (unless it's open by "default" but i don't think so).
And yes... i always use rsync to move files even within the machine because of the confort of the --progress parameter.
 
I've long had Samba servers running on my FreeBSD machines, and attached to them from my Windows machines, but until tonight hadn't tried mounting them from other FreeBSD machines.* I got things to the point where I could successfully use smbclient, but ran into problems when moving on to mount_smbfs. Investigating the problem, I found this thread. I see that the answer is "Use NFS instead (or throw caution to the wind by intentionally allowing SMBv1 clients)", and I'll therefore start investigating NFS (which I'm currently completely unfamiliar with). That's fine; however, I have to admit that I am very curious:

Why is there (apparently) no mounting option for Samba except for one that uses a protocol with known security issues that has been deprecated for over a decade now? It seems... crazy. Is it just a resource issue like "no one has made a more up-to-date version", or is there some underlying reason why doing so would be problematic? To be clear, I'm not complaining; just surprised and curious.

*: actually I have a vague memory of having done this a long time ago, but I think it was before v2 even existed, and I'm certain it was before v1 was deprecated
 
Why is there (apparently) no mounting option for Samba except for one that uses a protocol with known security issues that has been deprecated for over a decade now? It seems... crazy. Is it just a resource issue like "no one has made a more up-to-date version", or is there some underlying reason why doing so would be problematic? To be clear, I'm not complaining; just surprised and curious.
It is as simple as "someone has to make it happen". I've heard a few times people were actually working on it, but so far didn't see it happen. The "pain" is relatively small, as NFS is the de-facto standard in the Unix cosmos and with many FreeBSD installations running as servers, it's typically not a huge issue to use NFS there if it isn't the case anyways already. NFS is much simpler (and people say performs better). Classic NFS doesn't provide any security which could be an issue, but then, NFSv4 offers strong security with kerberos. I've written a howto about using Samba's "active directory" for that.

Nevertheless it would be very nice to also have client support for "modern" SMB, as there are environments (your typical "Microsoft Network") offering only that, so it would allow to easily integrade a FreeBSD installation in such an environment. But what really annoys me is that the current SMB client implementation wasn't dropped long ago (because in practice, SMBv1 is useless, all servers disallow it by default). People see it's there and the questions keep coming, followed by the frustration to learn it isn't fit for the purpose.
 
It is as simple as "someone has to make it happen". I've heard a few times people were actually working on it, but so far didn't see it happen. The "pain" is relatively small, as NFS is the de-facto standard in the Unix cosmos and with many FreeBSD installations running as servers, it's typically not a huge issue to use NFS there if it isn't the case anyways already. NFS is much simpler (and people say performs better). Classic NFS doesn't provide any security which could be an issue, but then, NFSv4 offers strong security with kerberos. I've written a howto about using Samba's "active directory" for that.

The reason NFS doesn't provide the security we expect is that the NFS server only secures files owned by root by translating root (UID 0) to nobody (UID 65535) before transferring over the wire.

The rest of NFS security is implemented in the client. This is insecure in that if the client is administered by someone other than the NFS server sysadm the responisibility for security is split and can be compromised. Take this for example:

You have UID 1000 and your files are exported to an NFS client who's UID 1000 belongs to someone else. They automatically have access. To resolve this,

1. The NFS server and NFS client must administered by the same person or group of people.

2. /etc/passwd and /etc/group on both machines must be in 100% harmony. On a network this is a PITA. This is why Sun and others implemented NIS, NIS+, and LDAP, to maintain a central database of users and groups.

I managed a site like this at $((JOB-1)). My network at home is configured this way. I maintain my passwd(5) and group(5) with LDAP and NIS (legacy).

In larger networks one would use the automounter to mount users' home directories when the log in (actually when /home/$USER is referenced).

It works but the sysadmin group needs an intimate understanding of UNIX, the network, NFS, NIS/NIS+/LDAP to make it work without security holes. In today's heterogeneous environments this is a virtual impossibility.

The SMB protocols are a horror show.

NFSv4 attempts to solve many of these problems. User/group mappings are negotiated between NFS server and NFS client. But again certain rules must be followed, such as they must share the same domain name (see domainname(1)).

You can make it secure but you *really* need to know what you're doing. My sensei at the time was a good teacher.

Nevertheless it would be very nice to also have client support for "modern" SMB, as there are environments (your typical "Microsoft Network") offering only that, so it would allow to easily integrade a FreeBSD installation in such an environment. But what really annoys me is that the current SMB client implementation wasn't dropped long ago (because in practice, SMBv1 is useless, all servers disallow it by default). People see it's there and the questions keep coming, followed by the frustration to learn it isn't fit for the purpose.
Yes. Linux has it and we use it all the time at $JOB to mount shares exported by Windows file servers. In an enterprise environment this capability is absolutely necessary. (We manage 1400 Linux servers, 600 Solaris, and 8000 Windows servers.)
 
NFSv4 attempts to solve many of these problems. User/group mappings are negotiated between NFS server and NFS client. But again certain rules must be followed, such as they must share the same domain name (see domainname(1)).
I don't think that's correct, the NIS/YP domain is not relevant for kerberized NFSv4. What's needed is a single kerberos realm and users mapped to the same directory.
edit: I think I understand how that can be relevant, if NIS is your "user directory" used to share accounts on multiple machines. But then, LDAP-based directories are (I think) much more common nowadays.

You can make it secure but you *really* need to know what you're doing. My sensei at the time was a good teacher.
The mechanisms can actually be simple. I'd say if your network is simple (one kerberos realm mapped to one "domain" in your directory), it's relatively easy to get it running securely. Mounting with a host-based initiator gave me some headache with the directory managed by samba. It would have worked out of the box if FreeBSD's mount_nfs(8) could just use the Windows "machine account" (HOST$) for that like the Linux client can, but unfortunately this isn't the case. Once I had that sorted out, it "just worked" for me (encrypted traffic, no access without a kerberos ticket for the NFS server).

If your network is large and complex, probably having multiple domains and realms and some trust relationships between, I would have no idea how to handle kerberized NFS indeed, so, agreed about that.

Yes. Linux has it and we use it all the time at $JOB to mount shares exported by Windows file servers. In an enterprise environment this capability is absolutely necessary.
... as long as this environment evolved around some Microsoft infrastructure. Yes, I know that's the case for the vast majority of enterprises...
 
Classic NFS doesn't provide any security which could be an issue, but then, NFSv4 offers strong security with kerberos. I've written a howto about using Samba's "active directory" for that.

Could you link to that, please? I'd like to read it.
 
Back
Top