0

I run Tails in a virtual machine on a Debian 9 host. To access a shared folder on the host via Tails, I try to set up a Samba-exchange.

While this approach worked completely fine in Debian 8, it does not work anymore in Debian 9. I always get the following error when trying to connect to the Samba-share:

"Unable to access location. Failed to retrieve share list from server: Connection timed out."


In QEMU-settings I specified the network source (virtual network interface) as bridge with name virbr0, device model is virtio. When running the machine the bridge is activated, physical network interfaces are activated as well and the guest (= Tails) receives internet access without any problems. Only the Samba-share does not work.

My /etc/samba/smb.conf looks like that:

[global]
workgroup = WORKGROUP
netbios name = MYCOMPUTER
name resolve order = bcast
dns proxy = no
log file = /var/log/samba/log./%m
max log size = 50
panic action = /usr/share/samba/panic-action %d
server role = standalone server
map to guest = bad user
usershare allow guests = yes
security = user
server string = %h server (Samba, Ubuntu)
bind interfaces only = yes
interfaces = enp0s25 virbr* lo

[Windows-SMB]
comment = Shared Samba Network Drive for Windows
path = /home/user/Public/Windows-Exchange
public = no
guest ok = no
browseable = yes
writeable = yes

[Tails-SMB]
comment = Shared Samba Network Drive for Tails
path = /home/user/Public/Tails-Exchange
public = no
guest ok = no
browseable = yes
writeable = yes

I tried all possible solutions:

  • Installing the package gvfs-bin

Edits in /etc/samba/smb.conf:

  • added netbios name = NAME-OF-PC
  • added name resolve order = bcast host

However, none of them worked.


I tried to narrow down the source of the error:

testparm does not detect any mistakes, smbtree displays all shares correctly. If I take the displayed IP-address from nmblookup <hostname> and insert this one into Tails, I get the mentioned error again.

However, pinging the Samba-share-IP from the guest works fine. I just can not access the share with the Tails file browser.

Some other ideas where I could look at?

The command smbclient -L host brought me "Connection to host failed (Error NT_STATUS_UNSUCCESSFUL)". However, if I type smbclient -L 192.168.178.31 I successfully get the table with the shares.


Here are some screenshots of the current situation:

Configuration checks via CLI:

user@hostname: ~$ smbtree
WORKGROUP
   \\HOSTNAME                  HOSTNAME server (Samba, Ubuntu)
        \\HOSTNAME\IPC$             IPC Service (HOSTNAME server (Samba, Ubuntu))
        \\HOSTNAME\Tails-SMB        Shared Samba Network Drive for Tails
        \\HOSTNAME\Windows-SMB      Shared Samba Network Drive for Windows

user@hostname: ~$ nmblookup
192.168.122.1 HOSTNAME<00>

(This seems to be fine)

Virtual Machine Manager:

Physical network-Interfaces in QEMU virtual manager: enp0s25

Physical network-Interfaces in QEMU virtual manager: lo

Virtual network-bridge "virbr0" that Tails should use

Gnome Network Manager:

Gnome Network Manager:

Error in Tails when connecting to the Samba Share IP via file browser:

Error in Tails when connecting to the samba share via file browser

Tails (successfully?) sending ping to the Samba-Server-IP:

Hereby both IP's seem to work fine: 192.168.122.1 as well as 192.168.178.31 (from a previous try before restarting the samba-server).

Ping to Samba-Server in Tails


Update: Samba-exchange is still not working.

Maybe interesting: Very frustrated about this Samba-issue I reinstalled my Debian 9 host several times because I thought I did a mistake anyhow. Hereby I think to remember the following fact: The first time I installed Debian and wanted to start Virtual Machine Managers default network bridge virbr0 I got an error that no firewall has been detected. Therefore Virtual Machine Manager did not want to start this bridge. I never received such a warning before, so I deleted the default network bridge and recreated a new one with identical settings and the same name. However, manually starting this new bridge was easily possible without any problems. Although still no firewall has been installed Virtual Machine Manager accepted the new bridge without complains. I think to remember that this time I got the Samba-exchange working.

However, I did a whole reinstall of the host system because some other things did not work and I played a lot with packages in the meanwhile. Hereby I figured out that this error message "No Firewall has been detected" was caused by missing packages firewalld and dnsmasq. I installed those packages and never got Samba exchange working again.

Unfortunately I am not that much into Linux to figure out the mistake by myself. Maybe it is just an easy thing with IP-settings of the firewall or something like this...

Another stupid behavior of Samba is the fact that directly after restarting the Samba server by command /etc/init.d/samba restart the smbtree-command does not work straight ahead. I have to wait several seconds sometimes until I do not receive an empty line anymore and the tree is displayed.

Furthermore the smbtree command only shows one output line with the hostname sometimes, but without naming the created Samba shares. This behavior seems to be influenced by the options in smb.conf. The upper presented smb.conf invites smbtree-command to correctly show the shares in its output as well. However, if I do a very simple [global] section with only two basic entries, sometimes the output of smbtree remains completely empty - I don't know why.

On my Debian 8 host machine with identical settings the smbtree-command output indeed is only one line as well. Maybe there is a bug anywhere? Normally smbtree should show the host name and the Samba shares as well. At least the Samba exchange is working on this Debian 8 system (no firewalld and no dnsmasq are installed here).

  • I'm curious, are those two machine on the same subnet? – D'Arcy Nader May 1 '18 at 21:39
  • @D'Arcy Nader: Thanks for your comment! How could I figure that out? I will upload some screenshots to explain the error, wait a few seconds... – Dave May 2 '18 at 4:52
1

you are using broadcast ( bcast ) to resolve the name but you have your machines on different subnet.

broadcast name resolving only works on the same subnet.

you must add an entry to your /etc/hosts on the tail host that says:

192.168.178.31    hostnameofthesmbserver

you can do that with this command:

sudo nano /etc/hosts

always check this file on reboot because i don't think tail will keep this change persistent.

  • First, thank you very much for your great help! In my Debian 8-host there was no need to edit Tails' /etc/hosts file to access Samba on the host (of course, in this time without the name resolve order-command). For experimenting I removed this command from current smb.config, but still the same situation: smbtree shows all shares, and also nmblookup HOSTNAME displays the (probably) correct IP-address. Maybe interesting: Also Windows can NOT access/see its share, so I think there is another problem anywhere? – Dave May 2 '18 at 7:45
  • i didn't say to delete that line on your smb.conf. i said something different, why don't you please try what i suggested? – D'Arcy Nader May 2 '18 at 7:48
  • Oh, I am sorry! That was my mistake... I readded the line to smb.conf and to my upper explanation as well. Now I added your recommendation into /etc/hosts, but still the same error. Afterwards I tried to restart networking in Tails with systemctl restart networking, but this also did not help. Even copying my previous smb.conf from the mentioned (successful) Debian 8-host into the new Debian 9-host did not work. I guess there is some mistake in the QEMU-bridge-configuration? When using Debian 8, Windows and Tails could access the samba-shares without any further edits in the guests... – Dave May 2 '18 at 8:15
  • why don't you try a simpler smb.conf , so you can understand faster where is the issue? – D'Arcy Nader May 2 '18 at 8:18
  • Even if I try the most simplest smb.conf (unix.stackexchange.com/q/418410/241507), I do not even get an output for smbtree or nmblookup <MYHOSTNAME> anymore. Comment: nmblookup <MYHOSTNAME> fails with the following message: "name_query failed to find name <MYHOSTNAME>". – Dave May 2 '18 at 8:29
0

A colleague figured out the problem:

By default Samba is getting blocked by firewalld. Therefore it was necessary to install the package firewall-config to activate Samba in Firewall. Probably this would be possible without a GUI as well, but with firewall-config it is a task of 10 seconds... Mention to activate Samba in Firewall as permanent, not only for current session.

Now everything works fine!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.