Could not mount images folder /bin/fog/.upload
-
Also, please ensure the /images/.mntcheck and /images/dev/.mntcheck files are present.
These are just empty files but they’re used to detect that the NFS is indeed connected.
This can be done with:
sudo touch /images/{,dev/}.mntcheck && sudo chmod -R 777 /images
-
So I believe I solved this - your chmod is exactly right - I was chewing on the /images permissions owner last nght, got into the office and looked at it with fresh eyes…simple problem, simple solution.
[root@FOG /]# ls -la images/ total 0 drwxrwxrwx. 4 root root 61 Mar 8 18:04 . dr-xr-xr-x. 20 root root 284 Mar 8 17:33 .. drwxrwxrwx. 3 root root 46 Mar 8 18:02 dev -rwxrwxrwx. 1 root root 0 Mar 8 18:00 .mntcheck drwxrwxrwx. 2 root root 30 Mar 8 17:33 postdownloadscripts
[root@FOG /]# chown -R fog images/
[root@FOG /]# ls -la images/ total 0 drwxrwxrwx. 4 fog root 61 Mar 8 18:04 . dr-xr-xr-x. 20 root root 284 Mar 8 17:33 .. drwxrwxrwx. 3 fog root 46 Mar 8 18:02 dev -rwxrwxrwx. 1 fog root 0 Mar 8 18:00 .mntcheck drwxrwxrwx. 2 fog root 30 Mar 8 17:33 postdownloadscripts [root@FOG /]#
I then bounced my test client and it picked up its capture task immediately as it did in my test lab. (Test lab in esxi server hosting fog to a pc on same vlan hosting test client in vmware workstation worked 1st try. Implementing this in a Windows Domain environment was still easy with the exception of this one speedbump)
To be utterly complete I will still need to Deploy a Captured image.
This solution is painfully obvious I admit, Your tutorial is excellent- however I might suggest for those following it to spec this albeit obvious permissions update might be included as optional for this error only?
-
@thequicken the permissions by default are already fog:root I don’t know why yours weren’t. I am thinking you changed them at some point when you were trying to get things working. Which is not an issue now, you got it going.
-
@Wayne-Workman i know that “back in the day” we had weird permissions issues that could happen if people created a user named “fog” when they set up the computer, and especially if they used that user to run the installer (this in spite of the instructions for setup explicitly saying not to create a user named “fog” because the installer would create one. of course, i discovered this bug the first time i set up a fog server, because that’s what i did…)
perhaps this is related since OP mentions logging in as the user “fog” which is typically not done
-
@junkhacker
(i create an ‘foguser’ but not ‘fog’)
Update - I rebuilt the server from the ground up again to ensure I did not miss anything.I did.
This was still required:
[root@FOG /]# chown -R fog images/
But there was another posting with nfs-server references that I used as well
I needed to start the nfs server:
[root@FOG /]# systemctl status nfs-server [root@FOG /]# systemctl start nfs-server [root@FOG /]# systemctl enable nfs-server
Working great so far
-
On build #4
Did not create a user - logged in and installed all as rootBuild#5
created my standard non-admin user to log into and install all using su.Both of these builds resulted in root:root permissions until corrected.
-
@thequicken As I stated earlier, if the permissions are 777 all the way up the directory tree, the ownership of the /images folder doesn’t matter. 777 is essentially “Give everybody and the world full permissions”.
-
@Tom-Elliott said in Could not mount images folder /bin/fog/.upload:
@thequicken As I stated earlier, if the permissions are 777 all the way up the directory tree, the ownership of the /images folder doesn’t matter. 777 is essentially “Give everybody and the world full permissions”.
Apparently it does matter if all he did was change ownership and suddenly everything works. I’ll look into this more sometime soon.
Saint Patrick’s day weekend is upon us and that’s a pretty big deal in my family. I’ll probably not have much time this weekend, probably early next week night can check it out.
-
@Tom-Elliott
777 should be cut and dry-- I’m the first to suspect error to be mine.
I am more than willing to do a fully documented build if you like. I have a shiny new Compellent with some top end ESXI hosts at my disposal- installation from OS to Fog takes no time at all.
My build in my isolated home lab worked completely 1st try- building in our domain environment added a few extra mods as expected but I was not expecting these errors. -
I am running into a similar issue. Or maybe not?
Tue Mar 28, 2017 20:53 pm
Running Version 1.4.0-RC-1
SVN Revision: 6069Mounting File System: Failed
Could not mount images folder (/bin/fog.upload)
Args Passed:
Reason: mount: mounting [IP_ADDRESS_HERE]:/images/dev on /images failed: Permissions deniedI suck at linux. I am a Windoz admin. I always followed FOG tutorials and got my FOG server running for years. I typically never touch it. I had an issue a few months ago regarding UEFI based images and installed the latest trunk. Since then I got this issue trying to upload/capture images.
Again I apologize in advanced. I read this thread several times but I’m not even sure if there is a fix throughout those posts or not. I guess I need some “translation” or being told where to get help. Sorry…
-
Anyone? Do I need to provide more information?
Using CentOS 7
-
@lmorel12 did you try the same things that solved the problem for OP?
for future reference, it’s best to create a new thread for issues unless you’re absolutely certain the issue is the same and it is still unsolved. new posts in a “solved” thread can get ignored very easily. -
@Junkhacker Thanks!! I do a lot of monkey-see-monkey-do stuff. So I assume I did what others did to make this work. I applied the chmod -R 777 stuff as well. I checked the NFS services and it’s running.
I can’t say I am troubleshooting because I am applying “fixes” I found through this tread. i know, I know, that’s scary.
I will follow your advice and create a new thread. I suspect some will point me to this thread for resolution but let’s see what happens.