I am setting up a Serva server for Ubuntu, per these instructions, and I can't seem to get Ubuntu to load on my client machine. The config file (from that link, which says it has been tested on Ubuntu 14.04.1 desktop):

asset    = Ubuntu LTS 14.04 Desktop Live
platform = amd64
kernel   = NWA_PXE/$HEAD_DIR$/casper/vmlinuz
append   = showmounts toram root=/dev/cifs initrd=NWA_PXE/$HEAD_DIR$/casper/initrd.lz,NWA_PXE/$HEAD_DIR$/casper/INITRD_N11.GZ boot=casper netboot=cifs nfsroot=//$IP_BSRV$/NWA_PXE_SHARE/$HEAD_DIR$ NFSOPTS=-ouser=serva,pass=avres,ro ip=dhcp ro

I changed the NFSOPTS=-ouser=serva,pass=avres part to NFSOPTS=-o user=theserver, password=p4ssw0rd because it had initially complained that -ouser was a bad option. theserver and p4ssw0rd are the username and password of the user account on the server machine (Windows 7). I have also shared the appropriate Serva folder, per the instructions.

Could someone take a look and see if it's a problem with my config file? Or could someone with more experience tell me what I'm doing wrong?

  • What is a "Serva"? You should clarify that soon - I first thought it is a very wrong spelling of server, hinting to a very low quality question... Aug 12, 2014 at 20:37
  • @VolkerSiegel ahhh...that is a good point. thanks.
    – yiwei
    Aug 12, 2014 at 22:29
  • For a Windows 10 SMB share on my domain sec=ntlm needed to mount the share also i used domain=mydomain in ServaAsset.inf. Oct 6, 2017 at 10:46

5 Answers 5


I had exactly the same problem today.

The problem occurred because the initial core Linux system (as it was booting) was unable to log on to the NWA_PXE_SHARE on my Windows 10 PC - Windows 10 has tougher security for shares than previous versions of Windows.

My solution:

  1. I added sec=ntlm to the NFSOPTS in ServaAsset.inf. This revealed an "access denied" error instead of the bad parameter or bad option error which is a red herring. The bad option error was reported because when the cifs logon fails, it then tries to access an NFS share which does not accept -ouser=xxx.

  2. On the Windows 10 machine I made sure that the "serva" user had explicit read permissions on the "C:\SERVA_REPO\NWA_PXE" folder AND that the "serva" user had explicit sharing permissions set for the NWA_PXE_SHARE share.

Then it worked. I arrived at this conclusion by testing the share from another (weaker) operating system which also worked.

  • 1
    Serva troubleshooting section vercot.com/~serva/an/NonWindowsPXE3.html#troubleshooting describes the server side parameters and the client options in order to avoid lowering the security more than necessary.
    – Pat
    Dec 5, 2017 at 22:11
  • Most ServaAsset.infs in that page already specify that security protocol (even back then, though idk if the deprecation of SMB 1.0 couldn't have affected some). Anyhow NFSOPTS seems to be kept together with duck tape too. It's parsed in initramfs and the nfsmount that should eventually call mount.cifs comes from klibc.
    – mirh
    May 11, 2022 at 12:01

For me adding only 'sec' didin't resolve my problem, after debugging, i found that i need vers too:

  • vers=1.0 appeared as a new requirement on Ubuntu 17.10 Live, never before
    – Pat
    Dec 5, 2017 at 22:07

I too was facing CIFS share access issue while network booting via Serva server. After much trials I realized that the username required the domain as well, since my Network share was hosted on a domain joined machine. Based on suggestions via internet, I was able to network boot successfully by appending text domain=<username domain> to the NFSOPTS param in the "ServaAsset.inf".

The NFSOPTS looked like following for me:

NFSOPTS=-ouser=<username>,pass=<password>,domain=<username domain>,ro

you have to read Serva instructions. i.e. Serva considers that the NWA_PXE_SHARE has a user with minimally reading access called serva with a password avres then you get


in your case that part of the line should be


what you did adding a space after -o is wrong.

if initially the booting says that the -ouser option is not recognized you either.

  1. didn't create the NWA_PXE_SHARE correctly
  2. didn't download/copy INITRD_N11 correctly

bottom line: follow Serva instructions to the letter and you will not fail.


Default config of the serva expects share name of NWA_PXE_SHARE, directory name is NWA_PXE, ensure that your config is correct. Quick way to check is to type in explorer address bar:

\(your address)\NWA_PXE_SHARE

and see if it will get to the main dir, if not, then you have to change config name to cover the share name or add share that will match NWA_PXE_SHARE (I would post the ss how to, but I don't have the english version of Win10).

If you can access it, then you should check one more thing (this is from the main page of Serva)
Go to gptedit.msc and go to:

Computer Configuration -> Windows Settings -> Security Settings -> Local Policies Security Options

And in the tab Network security check LM and NTLM.
That's it. I hope it will resolve your problem.

EDIT: All of this went fine till this point, until I got HP laptop workstation, then you should just ensure that you use ntlmv2 vers 2.0 in config file, and that worked for me

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .