Samba, Windows, *nix, SELinux and you

Let’s face it: SMB/CIFS comes in handy plenty of times. Works great under Linux, works great with Windows, and if it’s configured properly it’s fun times for everyone. There are multiple potential behavioural problems though, mostly involving charsets.

Samba charset (and filesystem) setup

While I’ve been successfully using iso-8859-1 by default for a long time in my Samba servers, until recently I also used the same charset in the *nix filesystem, which brought all kind of oddities. 20/20 hindsight, as per usual. In smb.conf, you can configurn though you can specify different charsets to make everyone happy:

dos charset = iso-8859-1
unix charset = utf-8
preserve case = yes
short preserve case = yes
default case = lower
case sensitive = no

This has multiple advantages:

  • Windows gets its iso-8859-1 charset, and is happy;
  • Linux gets its utf-8 charset, and is happy;
  • preserve cases make sure that filenames aren’t changed while moving files across machines;
  • disabling case sensitive avoid weird behaviour under Windows.

This is the configuration I’ve been running for years, sharing files across Windows/Linux/OS X machines since Windows XP, and has been working perfectly.

Changing filesystem charset

If you’re switching the unix charset though, you might need to convert existing files/directories to the new charset. Cue in convmv:

convmv -f <from_charset> -t <to_charset> -r --preserve-mtimes <dir>

In my case:

convmv -f iso-8859-1 -t utf-8 -r --preserve-mtimes .

With this simple command I was able to mass rename thousands of files in one go. Note that you also need the --notest parameter to actually apply the changes, and not just list the files in a dry run.


While playing around Centos I stumbled into SELinux problems I wasn’t prepared for. Consider the following:

comment = Personal share
path = /home/<username>/share/
guest ok = no
browseable = yes
writable = no
create mask = 0660
directory mask = 0775
write list = <username>

Supposing the path actually exists, that the username is added to the samba user database and that the password is correct, everything should work fine. Except that it mostly likely won’t, because we need to configure SELinux on top of everything else:

restorecon -R -v /home/<username>/share/
chcon -R -t samba_share_t /home/<username>/share/

That’s all there is to properly setup and have the content accessible. Contrary to what other people claims, you don’t have to increase permissions in the samba path tree. A 0700 on the /home/<user> works perfectly fine.

CentOS 7 & DHCPv6

Sometimes instead of the usual SLAAC you might need or want to use DHCPv6. The dhcp package and a very short manual configuration will take care of everything for you on the server, but what about the client? What if you configured the DHCPv6 client but it is not working?

I setup both the server and the firewall, then I proceeded to configure the client, but it would always fail. No v6 traffic would hit the server machine, even though I added the DHCPV6C=yes on the client machine. After hours spent without a solution, I found a video with the answer: the problem is Network Manager! On top of adding the DHCPV6C parameter you also need to add NM_CONTROLLED=no. I ended up with the following /etc/sysconfig/network-scripts/ifcfg-ethX:


Perfectly disabled IPv4, IPv6 configured automatically, all fine and dandy. Happy fun times!

OSSEC troubleshooting

Today we continue the saga of things I was supposed to write down but didn’t, for reasons unknown. Suppose you migrated your OSSEC management server, or freshly installed what will be the new manager on a new OS. You import the keys, as described in my previous post, but the connection fails for one or both of these reasons:

  • ossec-remoted(1403): ERROR: Incorrectly formatted message from '<client_ip>'. – Pick your own adventure-style error message.
  • ossec-agentd(1407): ERROR: Duplicated counter for '<server_name>'. – Incorrect serials.

This has happened several times over the course of the last decade, due to client/server version mismatch, drive failures, and what have you. There’s a pretty brute-force way to solve these problems, though:

  • stop both server and client;
  • on the client, delete everything inside /var/ossec/queue/rids;
  • reimport the key on the client (unsure if this step is really needed);
  • start the server;
  • test that the client is working, via ossec-agentd -d -f.
  • if the client is working, start the service.

That’s it. There’s nothing that a good ol’ rm -rf * can’t solve.

Nvidia drivers and MSI support in Windows

Today I started searching for an old article of mine in regard to guest Windows VMs and the troubles with pass-through Nvidia cards. Picture me surprised when I found out that I never actually posted it, although the article has been in the back of my mind for the past two years or so. So, I’ll write it right now, since it contains valuable information that might help some people.

PCI pass-through

There are only a handful of problems with PCI pass-through of video devices:

  1. manufacturers are dicks. You can’t pass-through the first graphic card on consumer devices, because reasons. If you buy a workstation grade with the same hardware though, we’ll allow it.
  2. Nvidia is a dick. If the drivers on the guest sniff out that you’re running within a hypervisor, they won’t work. At all. They refuse to load.
  3. Nvidia is a dick. Although every card supports MSI mode as a replacement for line-based mode, every single time you install the drivers the MSI mode gets reset, as only the workstation/server grade drivers flag the system about message mode. You’re not using the card in a guest machine after all, right? Right?

So, here are fixes for the problems above, same numerical order:

  1. none. The best thing you can do is have GPU capabilities in the CPU. This could/should work (untested).
  2. there are ways to “unflag” a guest machine from the dom0. On KVM through QEMU you can specify a `kvm=off` for the CPU, or edit the machine with `virsh edit`.
  3. after the drivers are installed you can manually edit the Windows registry to enable MSI (also needs a reboot).

MSI and you

There are various arbitrary sources that can tell you why MSI is better than the default line-based counterpart, but when it comes to virtualization I can tell you the top reason why you want to switch to MSI: line-based is unstable. I’ve used my virtualized main workstation/gaming station for a while now, and the only times video card had troubles or the entire VM crashed, was because something between the drivers and the pass-through of the IRQ interrupts in line-based mode failed hard. Since the discovery of MSI I stopped having issues with the video card and everything runs butter smooth.

So, to recap:

  • Audio coming from the video card crackling? Switch to MSI.
  • Guest O/S crashing? Switch to MSI.
  • Video drivers throwing a fit? Switch to MSI.
  • Bored? Switch to MSI.
  • Switch to MSI.

Enable MSI

Checking is fairly simple, just open Computer Management’s Device Manager, and check if the NVIDIA Geforce <whatever> and the relative High Definition Audio Controller have a positive or negative value.

List by connection
MSI based

If the value you see is greater than zero, you should switch to MSI. In order to do that, you need to open the device properties and find the device instance path:

With that in hand, you can open HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\PCI path in the registry, and follow the device instance path to find the following:

With MSI disabled you will notice that the MessageSignaledInterruptProperties key is missing, as you will need to create it along with the DWORD MSISupported set to 1.

That’s all there is to it. You can now reboot the system and the drivers will use MSI mode. Any audio crackling coming from the monitors will be gone, and everyone will rejoice.

Import disk image into XCP-ng/XenServer

Importing a disk image into XCP-ng/XenServer is rather easy, you just need to find the correct VDI and import it using the appropriate `xe vdi-import`. In my case I wanted to test the current OpenWRT release, so:

# xe vdi-list
uuid ( RO)                : <vdi-uuid>
          name-label ( RW): OpenWRT
    name-description ( RW):
             sr-uuid ( RO): <sr-uuid>
        virtual-size ( RO): <size>
            sharable ( RO): false
           read-only ( RO): false

# xe vdi-import uuid=<vdi-uuid> filename=openwrt-combined-ext4.img

That’s it: OpenWRT is installed on Xen and already bootable. At this point you can even mount the OpenWRT drive and resize its partition to fully use the remainder of the space you allocated.

Auto IP assignment to a dom0 virtual interface – Part #2

As we saw eariler, with careful configuration and the use of my small service, we’re able to remote in the dom0 no problem, but the main pitfall I didn’t realize was there until a couple days ago, is that in that iteration of the service, now updated, we lost console and performance monitor for most of the VMs spawning after the UTM. I tried asking for pointers, but given the “experimental” nature of my setup, I was left on my own.

The problem

First of all, while I was setting things up I left an ip outside of the class I was using to the management interface, in order for it not to interfere. This resulted in consoles not working for about any VM, since instead of a specified class it was using

# xe console-list
uuid ( RO)             : <uuid>
         protocol ( RO): RFB
         location ( RO): https://192.168.4.x/console?ref=OpaqueRef:<ref>

Reconfiguration through `xsconsole` or Center don’t work, obviously, so the only thing left to do was to restart in safe mode and change to the proper subnet. So far so good.

Upon restart everything seems working, up to the time I actually start a different VM:

# xe console-list
uuid ( RO)             : <uuid>
         protocol ( RO): RFB
         location ( RO): https:///console?ref=OpaqueRef:<ref>

This time everything was configured properly, but it still wouldn’t work. As it turns out, somewhere between starting the VMs and setting up the network, the bridge loses its ip. Xapi doesn’t care in the slightest what IP you’re connecting to, so when it has to pass a link to a management section, it just looks up its management network bridge for the address binded to it and generates it.

The solution

The solution is pretty simple: on top of adding a /24 mask to the VIF you’re connecting to, you also need to add the same ip with a /32 mask to the management bridge:

# ifconfig
xapi1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet  netmask  broadcast

xenbr0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet  netmask  broadcast

Thanks to [SkiD] for moral support and reminding me that this configuration is actually valid, since in routing terms `xenbr0` doesn’t go anywhere.