I’m thinking it may have something to do with the fact that the folder is already a remote CIFS mount. The more I look into this it appears that there has never been support in Linux for re-exporting a CIFS share through NFS.

Given that premise, is there an alternative to NFS for FOG? Since I already have the CIFS shares, is there a way to have FOG point to a CIFS share instead of using NFS? I’d rather not have to deal with setting up Windows NFS services–it’s pretty clear in the forums that it is something quite a few people have had problems with, and I’d rather not introduce another service that needs to be maintained.

I’ll check permissions again, but as noted in the first post I did update /etc/exports with the new locations.

I’m new to FOG and I’m having a bear of a time trying to get what should be a pretty basic thing working–modifying the default storage group to point to remote storage.

Here’s my situation. I’m running FOG in a Virtualbox VM (Ubuntu 12.04) on a Windows 7 platform (will later be moved to a Windows 2008R2 Server after testing). I have a large SMB share on the Windows Server that I want to use for image storage. I’d rather not have to get into setting up NFS on the Window Server for a variety of reasons, so I’ve mounted the SMB share on the FOG server directly (/mnt/win/fogimages). Up to that point everything is fine. The mount works and I can manually see/edit data on the share via command line. The share is mounted such that the fog user is owner with 644 permissions.

Now comes the FOG configuration. Based on a variety of WIKI and other sources here is what I have done to modify the default storage group.

1. Edit the DefaultMember storage node settings in the web GUI. All I did here was change the “Image Path” to point to “/mnt/win/fogimages”

2. Updating the /var/www/fog/commons/config.php file with below:
   [CODE]define(‘STORAGE_DATADIR’, ‘/mnt/win/fogimages/’);
   define(‘STORAGE_DATADIR_UPLOAD’, ‘/mnt/win/fogimages/dev/’);[/CODE]

3. Updating /etc/exports as such:
   [CODE]/mnt/win/fogimages *(ro,sync,no_wdelay,insecure_locks,no_root_squash,insecure,fsid=1)
   /mnt/win/fogimages/dev *(rw,sync,no_wdelay,no_root_squash,insecure,fsid=2)[/CODE]
   And then restarting NFS services.

So, after all that, the web GUI reflects the proper free space and everything seems to be great. But upon booting a client to upload an image I get the following error:[QUOTE]* Mounting File System…Failed

mount: mounting 192.168.50.80:/mnt/win/fogimages/ on /images failed: Permission denied[/QUOTE]

So, just for kicks I tried to mount the FOG NFS share from another Linux machine. No go there either–it just hangs trying to mount.

Can anyone give any direction? All I want to do is use a Windows share for image storage. A variety of blogs seem to have accomplished this in the past, so I don’t know if there is something going on with v1.0.x different than previous versions in this area.

As a new FOG user, are there any quick tips to make sure there aren’t any catastrophes related to users booting PXE with a FOG server in an existing production network ?

I’ll be using an existing DHCP server that redirects PXE requests to the FOG server and I want to be dead certain that a random user isn’t going to be able to accidentally image their computer when booting up. There is is much info out there and so many complex configurations related to PXE so I thought I’d just ask for any quick pointers.

And if I missed a post or WIKI page that covers this I apologize.

Tom, do you mean the documentation shown as the installer runs? Maybe I’m missing something but I don’t see much except for a changelog included with the installer files. If you mean inline documentation within the installer then I didn’t pay enough attention while it was running. Sorry about the venting; just haven’t had any experience with FOG yet and am eager to get things up and running.

Are there other changes in v1.0.x that are going to be incompatible with earlier releases? Is there a document somewhere that describes any changes? Thanks.

[quote]undionly.kpxe is the new filename that DHCP option 67 should point to now?[/quote]
Might it not be a good idea to update all the info on the wiki/guide to reflect this fact especially for new users? I spent a half hour trying figure out why PXE boot wasn’t working and just about everywhere states “pxelinux.0” as the proper file.