Hopefully someone out there is able to help me fix the configuration of my simple home network. In this network, users connect to wireless router for access to the internet. Also attached to the router is a fileserver. It handles backups provides extra storage. Files on the fileserver are made accessible by samba/cifs for convenience. Since at least opensuse 12.1, the samba configuration is partially broken. These are the symptoms:
The fileserver can mount shared directories on itself, that is to say
works when performed on the computer with the 192.168.1.6 address.
Mounting shares on the fileserver using on another linux box (ip=192.168.1.12) using mount.cifs also works just fine.
Mapping of a shared drive on the fileserver from windows xp times out
Attempts to access the shares via dolphin using the smb:// protocol whether on the fileshare (192.168.1.6) or a linux client (192.168.1.12) fails even after providing username and password information. This may be the same or a different problem that mounting via windows xp.
I have reviewed log files on the server and client to see if I can find any hints, but there is nothing. I have read the samba/cifs documentation for clues to tuning of smb.conf to no avail. Any ideas on what is wrong and the fixes?
Next, forget about the need to make permanent network mounts and consider using on-fly-mounts, triggered by icons that runs Dolphin with the smb command. Permanent network connections (remote cifs mounts) made to other computers will slow down most file functions and unless you are making file copies every other task from a remote PC, its not really required. You need to decide if you are sharing user space or common folders, usable by all. As for Windows, its helpful to create the same Linux user names and passwords as on your Windows computer. For Windows 8, consider creating a local user as well as your Internet Login and use the local login for Samba when needed. If you really want file sharing to work, read my blog to the end and get the bash script.
Mapping of a shared drive on the fileserver from windows xp times out
The file server looks like it is not configured appropriately.
Other things you say regarding the Linux boxes point to samba on openSUSE being correctly configured, so at this stage I recommend that you don’t fix it (because it’s probably not broken).
So then, about the “file server”: Is it a USB drive attached to a port on the router and shered from the Linux code in the router? Is it a computer attached by wireless or ethernet wire to the router? Is it a NAS box attached to the router? Please describe the “file server” in terms of its physical nature, how it connects to the router and how it is configured to share “drives”, including if it has an operating system and if it does, what form of networking is used therein.
It looks like more details about the layout of my fileserver and small network are in order. The fileserver is just a old laptop running opensuse 12.3. There is a large hard disk attached to it by USB. It is mounted onto /home at boot with fstab. User’s directories are under /home as is typical. Each user on the network has an account on the fileserver, and their home directories are configured to be shared by samba.
Here is where one of my problems shows up with just the fileserver. If I sit down and log directly into the fileserver, I can mount.cifs any of the user’s home directories, again on the fileserver, to another directory also on the fileserver. The fileserver is also running kde 4.10. Attempts to access a user’s directory with dolphin with the smb:// protocol dies. It just keeps asking for username and password without ever successful displaying the folder contents. There is a long delay between requests for username and password. It seems strange that mount.cifs works and smb:// does not.
With regard to networking, the fileserver is attached by ethernet cable to a netgear wireless router. The fileserver and clients are all on the 192.168.1.x subnet. My personal laptop is running opensuse 12.2, and I can mount.cifs to the fileserver successfully. It is also running kde4.10. The smb:// protocol under dolphin has the same behavior as when executed on the fileserver, request for username and password but no folder contents. smb4k works just fine, too.
It seems to based upon success with mount.cifs that the fileserver and client and configured properly. That connclusion is not backed up b by the behavior of the smb:// protocol in dolphin. Could there be a problem with smb:// in dolphin that is distributed with opensuse?
The other issue is accessing the fileserver from windows xp. Attempts to map a user’s folder on the fileserver timesout. It could either be the same problem as above or a second issue.
Hope this additional information helps diagnose and solve this networking problem.
I’m particularly interested also in the smb.conf from the fileserver.
Also please tell us what is the filesystem on the USB hard drive that’s mounted in /home.
Also please post back here the results of this command issues in a console on the fileserver: ls -l /home
Also, on the fileserver, please issue this command and post the results back here: sudo pdbedit -L
And this command on the fileserver too please: cat /etc/fstab | grep home
Sorry for the slow response, but work comes first. Thanks for your willingness to dig into my problems. The contents of the requested files are listed below. Any hints on how to add code block into postings?
dm1z:/home # ls -l
total 4
drwxr-xr-x 65 username users 4096 Apr 11 18:04 username
dm1z:/home # pdbedit -L
username:1000:User Name
dm1z:/ # more /etc/samba/smb.conf
# smb.conf is the main Samba configuration file. You find a full commented
# version at /usr/share/doc/packages/samba/examples/smb.conf.SUSE if the
# samba-doc package is installed.
[global]
workgroup = TUXBOX
passdb backend = tdbsam
printing = cups
printcap name = cups
printcap cache time = 750
cups options = raw
map to guest = Bad User
logon path = ""
logon home = ""
logon path = \\%L\profiles\.msprofile
logon home = \\%L\%U\.9xprofile
logon drive = P:
usershare allow guests = No
add machine script = /usr/sbin/useradd -c Machine -d /var/lib/nobody -s /bin/false %m$
domain logons = Yes
domain master = Yes
local master = Yes
os level = 65
preferred master = No
security = user
usershare max shares = 100
wins support = No
wins server =
[homes]
comment = Home Directories
valid users = %S, %D%w%S
browseable = No
read only = No
inherit acls = Yes
[profiles]
comment = Network Profiles Service
path = %H
read only = No
store dos attributes = Yes
create mask = 0600
directory mask = 0700
[users]
comment = All users
path = /home
read only = No
inherit acls = Yes
veto files = /aquota.user/groups/shares/
[groups]
comment = All groups
path = /home/groups
read only = No
inherit acls = Yes
[printers]
comment = All Printers
path = /var/tmp
printable = Yes
create mask = 0600
browseable = No
[print$]
comment = Printer Drivers
path = /var/lib/samba/drivers
write list = @ntadmin root
force group = ntadmin
create mask = 0664
directory mask = 0775
[netlogon]
comment = Network Logon Service
path = /var/lib/samba/netlogon
write list = root
Client side smb.conf:
# smb.conf is the main Samba configuration file. You find a full commented
# version at /usr/share/doc/packages/samba/examples/smb.conf.SUSE if the
# samba-doc package is installed.
[global]
workgroup = WORKGROUP
passdb backend = tdbsam
printing = cups
printcap name = cups
printcap cache time = 750
cups options = raw
map to guest = Bad User
include = /etc/samba/dhcp.conf
logon path = \\%L\profiles\.msprofile
logon home = \\%L\%U\.9xprofile
logon drive = P:
usershare allow guests = Yes
[homes]
comment = Home Directories
valid users = %S, %D%w%S
browseable = No
read only = No
inherit acls = Yes
[profiles]
comment = Network Profiles Service
path = %H
read only = No
store dos attributes = Yes
create mask = 0600
directory mask = 0700
[users]
comment = All users
path = /home
read only = No
inherit acls = Yes
veto files = /aquota.user/groups/shares/
[groups]
comment = All groups
path = /home/groups
read only = No
inherit acls = Yes
[printers]
comment = All Printers
path = /var/tmp
printable = Yes
create mask = 0600
browseable = No
[print$]
comment = Printer Drivers
path = /var/lib/samba/drivers
write list = @ntadmin root
force group = ntadmin
create mask = 0664
directory mask = 0775
So I do not have time to look at each line, but I see in your server you say Domain Master=Yes. Do you know what that means?
domain logons = Yes
domain master = Yes
If you have not really setup a Domain controller, and I have no idea why you would do that at home anyway, that should not be used. Here is my smb.conf file I use on all openSUSE PC’s. None are Domain controllers and there is no need to be. Next, the Server Says “workgroup = TUXBOX” while the client says “workgroup = WORKGROUP”, which are not the same and would not be used if it were a real Domain. Here is my smb.conf file you could look at for an example.
# smb.conf is the main Samba configuration file.
# You find a full commented version at
# /usr/share/doc/packages/samba/examples/smb.conf.SUSE
# if the samba-doc package is installed.
# Samba config file created using SWAT
# from MY_PC (127.0.0.1)
# Date: Sun Mar 24 17:31:55 CDT 2013
[global]
workgroup = WINDOWSNT
# netbios name = LinuxMaster
passdb backend = tdbsam
name resolve order = bcast host lmhosts wins
server string = "Master of the Universe"
printing = cups
printcap name = cups
printcap cache time = 750
cups options = raw
use client driver = yes
map to guest = Bad User
local master = yes
os level = 33
usershare allow guests = Yes
usershare max shares = 100
usershare owner only = False
hosts deny = ALL
hosts allow = 192.168.0.0/255.255.255.0, 127.0.0.1
max protocol = SMB2
[homes]
comment = Home Directories
valid users = %S, %D%w%S
browseable = No
read only = No
inherit acls = Yes
[Software]
path = /Software
read only = No
acl check permissions = No
inherit acls = Yes
guest ok = Yes
profile acls = Yes
[Windows]
path = /Windows
read only = No
acl check permissions = No
inherit acls = Yes
guest ok = Yes
profile acls = Yes
[DataSafe]
path = /DataSafe
read only = No
acl check permissions = No
inherit acls = Yes
guest ok = Yes
profile acls = Yes
[Multimedia]
path = /Multimedia
read only = No
acl check permissions = No
inherit acls = Yes
guest ok = Yes
profile acls = Yes
I have tried the two things you recommended. The first was to adjust the server-side smb.conf to the settings in your example, comment out the the Domain Master setting, and make corrections to the workgroup setting on the client side to match the server. After restarting the smb and nmb services, the server and client show exactly the same behaviors; mount.cifs works fine and smb:// protocol times out.
The second thing was to completely start over and configure samba from scratch with your sact tool. The interface and instructions are very nice. mount.cifs functions normally whether performed on the server or from the client. smb:// from dolphin is another matter. smb://192.168.1.7/uname timesout when performed from any location.
It seems like there must be something fairly obvous that I am missing given that mount.cifs functions normally.
I just updated SACT yesterday to version 1.06. You can grab the latest version by opening up terminal, copy the string below and past it into your terminal session and press enter:
The menus have been redone. Select option “6 . Samba Status, Testing and Log File Viewer Menu” and then option “3 . Run testparm on your default /etc/samba/smb.conf file” and lets see what errors might be found in your smb.conf files. Run it on server and client. I also include the ability to look at your smb and nmb log files for any errors that might show up there. For large posts, consider putting them here: SUSE Paste and give us a link there to your text post.
I have it working for reasons that I do not fully understand. The trick to expose the problem was to increase the debug reporting level on the server for both smbd and nmbd using smbcontrol. Once that was done, I compared the logs for accessing of the same share by mount.cifs on the one hand which works and smb:// through dolphin which did not. The logs show some type of naming or name resolution problem on the server side. A quick change to /etc/HOSTNAME to solve the contadiction allows share access via smb://.
While I am happy to accept that it works, I would like to know more about why it works. Why is name resolution different for smb:// than for mount.cifs? BTW, have you considered adding smbcontrol options into your sact tool to increase debug information.
So, in my blog I speak of HOSTNAME. Basically, you can set the Samba computer name in your /etc/samba/smb.conf file, or if the setting "netbios name = " is missing or remarked out, you use the Hostname as set by your openSUSE PC. If you set the same name in both places, which is not needed, it can cause odd problems and in any event, if you want both to use the same network name, then just use the one set by openSUSE and keep the one in /etc/samba/smb.conf remarked out or missing. I am happy to hear Samba is working for you and it might be interesting to compare your working /etc/samba/smb.conf file to your original.
On 4/13/2013 3:36 PM, cmrntnnr wrote:
>
> Hi jdmcdaniel3,
>
> I have it working for reasons that I do not fully understand. The
> trick to expose the problem was to increase the debug reporting level on
> the server for both smbd and nmbd using smbcontrol. Once that was done,
> I compared the logs for accessing of the same share by mount.cifs on the
> one hand which works and smb:// through dolphin which did not. The logs
> show some type of naming or name resolution problem on the server side.
> A quick change to /etc/HOSTNAME to solve the contadiction allows share
> access via smb://.
>
> While I am happy to accept that it works, I would like to know more
> about why it works. Why is name resolution different for smb:// than
> for mount.cifs? BTW, have you considered adding smbcontrol options into
> your sact tool to increase debug information.
>
> Thanks for you time,
>
> cmrntnnr
>
>
I see two different IPs and two different shares. Did you use actual NETBIOS names or did you use IPs? In the latter case, the
names of the machines should not matter. Did you try to connect to a different machine with Dolphin than the one you mounted with
mount.cifs? Did you try to access the same share?
NETBIOS names are limited to 15(+1) ASCII characters(A-Z plus some special characters). If the DNS hostname is longer than 15
characters, and the NETBIOS name is not set in smb.conf, Samba truncates the hostname to 15 characters to arrive at the NETBIOS
name. (I don’t recall how it handles non ASCII characters. But, you can look it up.) Thus, if your original hostname was long
and/or included non ASCII characters your NETBIOS name may have been different than what you might have expected. See: NetBIOS - Wikipedia
P.V.
“We’re all in this together, I’m pulling for you” Red Green
I have not had time to dig any more deeply into what made smb:// work on my home network. Just for clarifaction, my home network is very simple and is setup on a single subnet, 192.168.1.x. smb:// protocol now works when executed on the fileserver or any of the clients that I have whether they are linux, windows xp, or the app on my smartphone.
The issue is with the fileserver was somehow tied into its name. The hostname (/etc/HOSTNAME) of the fileserver was originally set to something like myhostname.mydomain.com. However, smb:// seemed to want the short name, myhostname. I changed hostname to be myhostname and voila, it works. I am being more rigorous now about separating short and fully qualified domain names in /etc/hosts and adding a search field in /etc/resolv.conf.
What no one has explained to me yet is this. Why does the samba server behave differently when interacting with smb:// than with mount.cifs. This is also true for windows xp with behavior like smb://.
In any event, I hope this trudge helps others who were facing the same problem. I would be happy to post /var/log/samba/log.smbd and its nmbd counterpart for mount.cifs and smb:// cases should any one ask for them.
On 4/14/2013 8:36 AM, cmrntnnr wrote:
>
> I have not had time to dig any more deeply into what made smb:// work on
> my home network. Just for clarifaction, my home network is very simple
> and is setup on a single subnet, 192.168.1.x. smb:// protocol now works
> when executed on the fileserver or any of the clients that I have
> whether they are linux, windows xp, or the app on my smartphone.
>
> The issue is with the fileserver was somehow tied into its name. The
> hostname (/etc/HOSTNAME) of the fileserver was originally set to
> something like myhostname.mydomain.com. However, smb:// seemed to want
> the short name, myhostname. I changed hostname to be myhostname and
> voila, it works. I am being more rigorous now about separating short
> and fully qualified domain names in /etc/hosts and adding a search field
> in /etc/resolv.conf.
>
> What no one has explained to me yet is this. Why does the samba server
> behave differently when interacting with smb:// than with mount.cifs.
> This is also true for windows xp with behavior like smb://.
>
> In any event, I hope this trudge helps others who were facing the same
> problem. I would be happy to post /var/log/samba/log.smbd and its nmbd
> counterpart for mount.cifs and smb:// cases should any one ask for them.
>
> cmrntnnr
>
> myhostname.mydomain.com truncated to 15 characters gives myhostname.mydo. Thus your netbios name was"myhostname.mydo". But you
never answered my question on whether you used names or IPs when accessing the machines.
–
P.V.
“We’re all in this together, I’m pulling for you” Red Green
It seems this thread can be marked solved. My home network works perfectly.
Mounting and browsing shares on the fileserver functions normally weather from win7, xp, linux, or droid. The server accepts either netbios names or ip addressing.
It does not look like this is the right forum to get an answer for the question I posed about different behavior of mount.cifs and smb://.
Let me say that I have not found it necessary to make a permanent mount from my fstab file using cifs to share files between PC’s It is my opinion that can slow down your desktop boot process, likely slows down most network activity by some amount even when not actively moving data between PC’s. I use KDE and I create two types of desktop icons that invokes smb connections, only active while Dolphin remains loaded and I use it for open shares that require no password and for /home shares that require a password. For anyone reading, have a look at this bash script for more details: S.A.C.T. - Samba Automated Configuration Tool - Version 1.03 - Blogs - openSUSE Forums
Now to your suggestion to mark the message thread as Solved, we don’t go back and add the word Solved to the Message thread Title. However, its OK to add the word Solved to your last message title as I have done here. Further, there is something called the Tag Cloud at the bottom of the message thread where you can add in the word Solved, which shows up on any search for that work. I shall do that for you.
You may certainly create a new message request to help in setting up cifs in your fstab file if you wish to do so and good luck in your quest.
My question is not how to put an entry in fstab to mount samba shares. The unanswered question originally posed was this:
Why was it possible to successfully do a mount.cifs to the fileserver when the smb:// such as from dolphin would not function? It seems somehow tied into naming or name resolution. mount.cifs worked whether using names or ip address and smb:// did not function under any circumstances.
While this thread can be marked solved as the desired outcome of a working home network was achieved, it would be nice to better understand what is happening in smb://.
The best way to answer that is to compare the exact text before and after the Samba configuration change was made. There are character type and size limitations and there is the “right” way to specify a hostname in Samba. Anything else you do can produce incorrect results, but how they manifest themselves is not exactly explained as you are trying to show how do it right as opposed to detecting all of the possible wrong things one can do. I don’t often get bogged down by why, but keep lots of examples of working configurations from which I may copy from.