Edit: sorry the title was supposed to be “Mounting NAS” not “Mounting NFS”

We went from a .32/Ubuntu 12.04 install on a stand-alone machine to a 1.1.2/Ubuntu 12.04 fresh install on a ported VM. We’ve gotten to the point that it will now boot up, but when you get to the mounting part, I get the “mount: mounting 10.0.6.99:/images/ on /images failed: Permission denied”. (10.0.6.99 is new server) We currently have a Lenovo EMC NAS drive with all of the images that’s mounted on boot via a script (when trying to mount via fstab, we were just getting all sorts of errors) that just does:

sudo smbmount //x.x.x.x/share /images -o user=x,pass=y (x.x.x.x is NAS drive)

If you actually go to the /images folder, you see all of the folders just like it’s local, so it does mount properly. I’ve also done the touch commands to create the .mntcheck in /images and /images/dev. The NAS drive has NFS (Allow all client users full access), rsync, Web Access (HTTP, HTTPS), and Windows File Sharing turned on; Apple File Sharing, FTP, TFTP, Bluetooth, SNMP, WebDAV, Windows DFS are turned off.

I’ve already read this post: [url]http://fogproject.org/forum/threads/permission-denied-when-trying-to-image-after-update-to-1-1-1-1-1-2.10941/#post-31487[/url], and here’s my report.
[LIST]
[]My /etc/exports file does point to /images and /images/dev.
[]I’ve restarted the NFS service, gives about the same report at exportfs -va below.
[]exportfs -ua does nothing, exportfs -va gives:
exportfs: /etc/exports [1]: neither ‘subtree_check’ or ‘no_subtree_check’ specified for export ":/images". Assuming default behaviour (‘no_subtree_check’). NOTE: this default has changed since nfs-utils version 1.0.x

exportfs: /etc/exports [2]: neither ‘subtree_check’ or ‘no_subtree_check’ specified for export “*:/images”. Assuming default behaviour (‘no_subtree_check’). NOTE: this default has changed since nfs-utils version 1.0.x

exporting :/images/dev
exportfs: /images/dev does not support NFS export
exporting :/images
exportfs: /images does not support NFS export
[]selinux is disabled
[]I can now start a debug task, and when I do
[FONT=Consolas]mkdir /images[/FONT][FONT=Consolas]mount -o nolock,vers=3 IP.OF.YOUR.FOG:/images /images[/FONT]I get the exact same error about the permissions as before.
[/LIST]
I’m thinking that maybe it has something to do with why the exportfs says that the folder doesn’t support NFS export. I’m not sure what that issue is or how to fix it. It could also have a file permission on the folder problem. When I do an [I]ls -la[/I] on /images, I get [I]drwxr-xr-x 0 root root 0 June 6 09:04 SILVERBASIC[/I](this is the same for the rest of the image folders). I’ve run the command “chmod 777 -R /images” but it does not change the files to 777. If I try to sftp (from WinSCP), it shows the files are 777.

If anyone needs any other outputs, let me know.

You guys all rock!

In production .32. It’s on an old clunker, and looking on testing 1.0.1 (although I’ll probably get it upgraded to 1.1.0 before we actually test it) on a VM that we ported over. If the porting doesn’t make it faster, we were going to try increasing the compression a click or two to see if it helps with the speeds.

If we change the compression levels (via method at [url]http://fogproject.org/forum/threads/compression-level.280/[/url]), does it make existing images (compressed on a different level) unusable, or does the system know that it was compressed at a certain level and adjust?

We just started using FOG where I work, and initially we had a static IP address setup with no host name set up. When creating our images, when installing the FOG client, we had to manually type the IP address because we didn’t have a host name. We recently got the fogserver default host name setup, but we’re about to change the IP address of the server as well.

How will changing the IP affect existing images that we’ve put out? We have all of the services turned on (host name changer, printer, etc.).