Could not mount images folder /bin/fog/.upload

[Wayne Workman]

Are you doing the optional steps too? Those are only needed if you have timing issues. Don’t do the optional steps. I modified the article to be more clear on that point.

The space issues is likely just a mistake with partitioning during OS installation. What is the output of df -h and lsblk ?

Of course you can hack and slash, everything in Linux is configurable. But we need to know those details so we can figure out where you’re going wrong, and help you to do it right or correct it.

[thequicken]

@Wayne-Workman

Hi Wayne, thank you for the prompt response - PDQ said you guys were helpful !
So this is my 4th build from the ground up - didn’t bother adjusting swap or boot (i’m not worried about space) – error is identical through.

As per your post-config timing options, I have tried with and without --the error remains.
My config will not allow the Client to upload its Capture image to the /image dir.
Fun fact- the fog dashboard clearly shows the Storage Node Disk Usage at 1TB.

[root@FOG ~]# df -h
Filesystem                                                       Size  Used Avail Use% Mounted on
/dev/mapper/cl-root                                               20G  5.4G   15G  27% /
devtmpfs                                                         3.9G     0  3.9G   0% /dev
tmpfs                                                            3.9G   84K  3.9G   1% /dev/shm
tmpfs                                                            3.9G  8.9M  3.9G   1% /run
tmpfs                                                            3.9G     0  3.9G   0% /sys/fs/cgroup
/dev/sda1                                                       1014M  227M  788M  23% /boot
/dev/mapper/cl-images                                           1021G   33M 1021G   1% /images
tmpfs                                                            783M   16K  783M   1% /run/user/42
tmpfs                                                            783M  8.0K  783M   1% /run/user/0
userx@127.0.0.1:/cygdrive/C/Users/userx/X2GO~1/S-ROOT~2/spool  225G  140G   85G  63% /tmp/.x2go-root/spool/C-root-50-1489040562_stDXFCE_dp32
[root@FOG ~]# 

---

[root@FOG ~]# lsblk
NAME          MAJ:MIN RM    SIZE RO TYPE MOUNTPOINT
sda             8:0    0      1T  0 disk 
├─sda1          8:1    0      1G  0 part /boot
└─sda2          8:2    0      1T  0 part 
  ├─cl-root   253:0    0     20G  0 lvm  /
  ├─cl-swap   253:1    0    7.9G  0 lvm  [SWAP]
  └─cl-images 253:2    0 1021.1G  0 lvm  /images
sr0            11:0    1    7.7G  0 rom  
[root@FOG ~]# 

I am more than willing to rebuild the entire OS/FOG from the ground up with snapshots of EVERY phase to help solve this.

Mod edited to use code boxes.

[Tom Elliott]

What’s the output of ls -lhartR /images?

When you applied the permissions, it appears you’ve set 777 recursively, but did the ownership remain as root:root or fog:root?

From the sounds of things, the problem isn’t at all with “permissions” necessarily, rather it sounds like a problem with NFS services.

Maybe:
systemctl status -l nfsd could shed some light?

Or:
systemctl status -l rpcbind

[Wayne Workman]

@thequicken This last time around you appear to have configured the partitions correctly, from the command output everything looks in order. Please run the below commands that Tom posted, we will go from there.

[Tom Elliott]

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

[thequicken]

@Tom-Elliott

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?

[Wayne Workman]

@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.

[Junkhacker]

@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

[thequicken]

@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

[thequicken]

@Wayne-Workman

On build #4
Did not create a user - logged in and installed all as root

Build#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.

[Tom Elliott]

@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”.

[Wayne Workman]

@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.

[thequicken]

@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.

[lmorel12]

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: 6069

Mounting 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 denied

I 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…

[lmorel12]

Anyone? Do I need to provide more information?

Using CentOS 7

[Junkhacker]

@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.

[lmorel12]

@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.