Permission Denied when trying to image after update to 1.1.1/1.1.2
-
[quote=“Jamie Rozek, post: 31440, member: 24394”]I’ve reset the fog user password on the server, thinking that could be the issue. I changed it to match the password in the error in my previous post.
I am still getting the error:
mount: mounting 192.168.3.8:/fog/images/ on /images failed: Permission denied.[/quote]
I tried to FTP into the server from a command prompt on my Windows box. I was able to get in using that username/password.
-
The message [CODE]mount: mounting 192.168.3.8:/fog/images/ on /images failed: Permission denied.[/CODE] is from NFS so it shouldn’t care about FTP or FTP passwords. I still suspect it is a network problem somewhere - your NFS configuration should be able to function with all of the fog services turned off. If you boot one of your clients with a debug task, once it gives you a shell, can you try
[CODE]
$ mkdir /images
$ mount -o nolock,vers=3 IP.OF.YOUR.FOG:/images /images
[/CODE]
This should be the NFS mount that your client is doing during an image. When you run that command you should be able to see the server logging the mount, e.g. in /var/log/messages on RHEL
[CODE]Jun 26 10:00:56 fog rpc.mountd[23650]: authenticated mount request from IP.OF.YOUR.CLIENT:720 for /images (/images)
[/CODE]
The log file location (and message) might be slightly different (depending on your distribution), but running “ls -lhrt /var/log” should tell you which log file was most recently changed.For the disk image sizes, it looks like those are partimage (fog < 1.0) images. This is a known problem, see[URL=‘http://fogproject.org/forum/threads/disk-information-and-image-size-on-server-not-showing-any-data.10953/’] this thread[/URL] for more details on it.
-
[QUOTE]For the disk image sizes, it looks like those are partimage (fog < 1.0) images. This is a known problem, see[URL=‘http://fogproject.org/forum/threads/disk-information-and-image-size-on-server-not-showing-any-data.10953/’] this thread[/URL] for more details on it.[/QUOTE]
Nope. They have all been made on 1.1.0 over the last few weeks.
As for the rest being a connection problem—I don’t see how. We haven’t changed a thing on our network. The ONLY thing that has changed is that we updated the Fog server. That’s it. It was upgraded to 1.1.1, and when that didn’t work – 1.1.2.
It was working just fine on 1.1.0. -
Output of ls -lhrt /var/log:
drwxr-xr-x 2 root root 4.0K Jun 26 07:03 unattended-upgrades
-rw-r–r-- 1 root root 235K Jun 26 07:08 dpkg.log
-rw-r----- 1 mysql adm 0 Jun 26 07:08 mysql.log
-rw-r----- 1 root adm 0 Jun 26 07:08 apport.log
drwxr-s— 2 mysql adm 4.0K Jun 26 07:08 mysql
-rw-r----- 1 syslog adm 1.3M Jun 26 07:08 syslog.1
drwxr-xr-x 2 root root 4.0K Jun 26 07:08 upstart
-rw-r----- 1 syslog adm 410K Jun 26 09:30 kern.log
-rw-r----- 1 syslog adm 5.3K Jun 26 13:22 syslog
-rw-r----- 1 syslog adm 72K Jun 26 13:23 auth.log
-rw-rw-r-- 1 root utmp 113K Jun 26 13:23 wtmp
-rw-rw-r-- 1 root utmp 429K Jun 26 13:23 lastlog -
Output of the SYSLOG: (It is refusing the mount request)
(Attached----it was reporting back as Spam when trying to post)
[url=“/_imported_xf_attachments/1/1078_syslog.txt?:”]syslog.txt[/url]
-
OK, so it looks like syslog would be the where NFS mounts are logged on your system, is it Ubuntu? I have an ubuntu machine image and I’m deploying it now. Once it is installed I’ll take a look at the NFS setup so we can compare. I’ll post back when it is up and running.
When I said I thought the network was the problem I meant the networking on the fog server you are running: the installer script runs yum updates and my guess is that a new version of one of these packages broke something.
-
[CODE]
Jun 26 13:22:56 troi rpc.mountd[1691]: authenticated mount request from 192.168.3.33:930 for /images (/images)
[/CODE]
Does this correspond with the fog debug task and mount command? did you get any output from that command? Could you turn on debugging for NFS, edit the /etc/default/nfs-kernel-server file to have the line
[CODE]
RPCMOUNTDOPTS=“–manage-gids --debug all”
[/CODE]
Then “service nfs-kernel-server restart” and retry the mount - syslog should get more information this time. -
What are the permissions of /images?
Can you try these steps:
[code]touch /images/{,dev/}.mntcheck
chmod -R 777 /images
service nfs-kernel-server restart[/code] -
Hi Jamie, I just noticed in your syslog
[CODE]
refused mount request from 192.168.3.33 for /fog/images (/): not exported
[/CODE]
The fog clients are trying to mount the wrong location, that is almost certainly the problem. Check the image path in your storage configuration, you would either need to update that or change your export list, once they match your NFS problem should go away (and probably the FTP one as well). -
Thanks, guys. I finally got it working. It was a mess…I must have just started changing things willy-nilly and stopped paying attention to what I was doing.
The export file, as ianabc stated was incorrect. I did:
nano /etc/exports
[SIZE=2]pointed the first line to [/SIZE]fog/images *(ro,sync,no_wdelay,insecure_locks,no_root_sq$
[SIZE=2]and my machines immediately started imaging.[/SIZE]The funny thing is that yesterday I’m almost certain I had a line in that file pointing to that path. Maybe I didn’t comment out the other one.
Either way, it appears to be working. Hopefully I didn’t change something else somewhere that’s going to drive me nuts!
Thanks!!!
