Mounting /images/dev Permission Denied

[vkenny]

Server

• FOG Version: 1.3.5
• OS: CentOS 7

Client

• Service Version:
• OS:

Description

Attempting to work my way through the creation of a backup solution with a repository of images stored on a Windows server. I have FOG setup on a CentOS 7 VM using VMWare & ESXi. My storage repository is a disk shelf connected into Windows Server 2012. I have a network cable directly connecting ESXi and the Windows server (will be routed through switch later ). NFS Share is setup in Windows Server, and a Virtual Switch opening up the network interface for the FOG Server. I have successfully mounted the NFS Share as a local drive in CentOS 7 as /images. Installed FOG as usual. Install went through without a hitch, .mntcheck in both /images and /images/dev. All permissions seem correct according to CentOS and FOG.
I am experiencing 2 issues:

1. When I try to access the Disk Shelf from within Windows I get access denied.

2. When I attempt to create an image from a workstation I get an error: Mounting /images/dev Permission denied and it reboots in 1 minute.

Anyone have any suggestions or ideas?

[george1421]

@vkenny If I understand correctly, you have a nfs share, shared on your windows box and then its mounted on your fog server. Then on your fog server you have them shared out again. This is now allowed in NFS land, but it is the same with windows. You can reshare a mounted share.

I did write a proof of concept tutorial for turning a windows server into what fog calls a storage node. ref: https://forums.fogproject.org/topic/6941/windows-server-as-fog-storage-node-proof-of-concept-blog

That document may give you a starting point for your setup. Once you have the windows server acting like a fog storage node, you can change (in fog) to make the windows storage node the master node.

Remember my document is just a proof of concept and not a finished document. If you care to follow it and provide any feedback we can perfect the document and then the wiki folks will convert it into a wiki guide.

[Tom Elliott]

@george1421 I think something is weird
For clarity.

An nfs share cannot be reshared.
Think of it like: you have two car keys to drive a car.

One person takes one key and drives the car. You may take your other key, but if another key is in the ignition your key won’t matter. Or if the car is in use your key won’t matter.

[vkenny]

nope its not shared out again on the FOG server. The Windows NFS Share is simply mounted as a local hard drive in the CentOS VM as /images. It is not shared again from the FOG server.

Everything is working as it shood. I have FOG installed, I can access the /images directory from the terminal, I can login to the fog server.

The only issue I have is that I cannot create an image. When I do I get permission denied to /images/dev.
I’ve tried the usual chown fog:root /images/dev… and chmod 777 /images… but nothing seems to work, no matter what I do I get permission denied /images/dev when I try to create an image.
If I try to change /images/dev to /images/dev1 I get location does not exist so I know its hitting the storage repository.

I cant seem to get the correct permissions to apply to /images/dev.

[Tom Elliott]

@vkenny how is the server mounting the share as a local drive?

[george1421]

@vkenny Can you post a clean screen shot of the error taken with a mobile phone? The context of the error is just as important in debugging as the error itself.

Also will you post the output of the following command: ls -la /images/dev

[vkenny]

I have given up and started over using the instructions given by @george1421 ref: https://forums.fogproject.org/topic/6941/windows-server-as-fog-storage-node-proof-of-concept-blog
Hopefully it works, i noticed the very last comment states he is at a stand still… Has this been converted into a Wiki yet? Does anyone know if this works?

I would love to keep everything *nix but my office and several folks that work with me, don’t agree. They believe the storage node should be managed with Windows so someone with no Linux experience can easily add/remove images which i do tend to agree with.

EDIT

Yes i can, i will post screenshouts and outputs in a few mins. I have yet to start over as i stated above, i was editing the instructions provided to fit my system before i began.

[vkenny]

@george1421
here is the output. Give me a few mins to edit the pic and ill upload it.

$ ls -la /images/dev
total 9
drwxrwxrwx. 2 fog root   64 May  4 17:11 .
drwxr-xr-x. 2 fog root 4096 May 10 10:02 ..
-rwxrwxrwx. 1 fog root    0 May  4 17:11 .mntcheck
drwxrwxrwx. 2 fog root   64 May  4 17:11 postinitscripts

[george1421]

@vkenny There is no need to edit the pict if you are using private IP addresses since there is no way for me to hack your network if you are using a private range like 192.168.1.x/24. Having actually IP addresses help with the debugging. The mac addresses I don’t care about.

[george1421]

@vkenny Your images directory looks good. I do have to ask you did you change the password or generall mess with the linux fog account? This is an internal account used by fog and people like to use it for local system admin for some reason. Understand this is the linux fog account and not the web gui fog admin account.

Also could you post the output of this command showmount -e 127.0.0.1? This command shows us what NFS has shared on your fog server.

[vkenny]

@george1421 Well, I’m not quite sure what account you are asking about, if you could be a bit more specific. I did not edit any accounts…
here is a pic of the error I receive from the laptop I am trying to create an image of.

[vkenny]

@george1421

$ showmount -e 127.0.0.1
Export list for 127.0.0.1:
/images/dev *
/images     *

[george1421]

@vkenny Will you post the output of this command showmount -e 127.0.0.1 This will show is what has been shared via nfs.

You posted the answer when I was posting the question. The output of that command look normal.

OK can you post the output of this command cat /etc/exports ?

[george1421]

@george1421 In addition to the exports as I asked in the previous post can you post the results of this? cat /etc/fstab There will be a lot of text in there.

[vkenny]

$ cat /etc/exports
/images *(ro,sync,no_wdelay,no_subtree_check,insecure_locks,no_root_squash,insecure,fsid=0)
/images/dev *(rw,async,no_wdelay,no_subtree_check,no_root_squash,insecure,fsid=1)

$ cat /etc/fstab
UUID=ca0220ba-82d7-434f-9231-74ba18706ac1 /                       ext4    defaults        1 1
UUID=20a99d10-8d99-429c-82b7-4c8655a22d22 swap                    swap    defaults        0 0
169.254.91.1:/FOG-Share /images                                   nfs _netdev,defaults,user,auto,noatime,intr   0 0
169.254.91.1:/FOG-Share /images                                   nfs _netdev,defaults,user,auto,noatime,intr   0 0

I deleted the uncommented lines since it seemed to convert these lines into larger bold text. I can add them back in if you wish. hank you for the support!!

[george1421]

@george1421 said in Mounting /images/dev Permission Denied:

If I understand correctly, you have a nfs share, shared on your windows box and then its mounted on your fog server. Then on your fog server you have them shared out again. This is now allowed in NFS land, but it is the same with windows. You can reshare a mounted share.

I am requoting this from my initial post because I feel I identified the issue in the first sentence.

In fstab you are connecting /images to an external nfs server 169.254.91.1:/FOG-Share Then using NFS you are sharing /images to everyone in your exports file. You are trying to nfs share an nfs mounted share (reshare a share). This has historically never worked with NFS (I actually don’t think this works with MS Windows either). Ignoring the fact about an nfs mounted share some nfs servers won’t let you mount a subdirectory of a share directly. So you would technically need a second line in your fstab for the /dev share like this:

169.254.91.1:/FOG-Share/dev /images/dev                                   nfs _netdev,defaults,user,auto,noatime,intr   0 0

To confirm my point (assuming you have enough space on the fog server for 1 image) key in umount /images on the linux server console and then recapture the image again.

[vkenny]

If I umount /images and try to create an image from a workstation, I get
“Could not mount images folder (/bin/fog.upload)
Args Passed:
Reason: mount: mounting 10.2.20.6:/images/dev on /images failed: No such file or directory.”

[george1421]

@vkenny If you run this command ls -la /images I’m going to suspect you are missing files since the nfs share was probably in place when you installed FOG.

This is what the output of the command should look like

pi@pi01:~ $ ls -la /images
total 20
drwxrwxrwx  5 fog  root 4096 Apr  4 06:37 .
drwxr-xr-x 25 root root 4096 May 10 15:41 ..
drwxrwxrwx  2 fog  root 4096 Apr  4 06:37 Base_XP
drwxrwxrwx  3 fog  root 4096 Apr  4 06:37 dev
-rwxrwxrwx  1 fog  root    0 Sep 24  2016 .mntcheck
drwxrwxrwx  2 fog  root 4096 Sep 24  2016 postdownloadscripts

and the output of /images/dev

pi@pi01:~ $ ls -la /images/dev
total 12
drwxrwxrwx 3 fog root 4096 Apr  4 06:37 .
drwxrwxrwx 5 fog root 4096 Apr  4 06:37 ..
-rwxrwxrwx 1 fog root    0 Sep 24  2016 .mntcheck
drwxrwxrwx 2 fog root 4096 Apr  3 19:06 postinitscripts

If you rerun the installer now without making any changes it will rebuild the /images directory with the necessary bits.

[vkenny]

right, It will work if I re-run the installer now and will create /images on local storage instead of the NFS Share.

Please explain in a bit more detail how I’m re-sharing an NFS Share. Its simply an NFS share from my Windows server to the FOG server. Does FOG somehow create a share? If so how would I use an NFS share as the primary repo for the images?

I’m am not connecting what I’ve done with your response that I’m re-sharing an NFS share…

[Tom Elliott]

@vkenny Your FSTAB is mounting an NFS share from your windows server to /images on your fogserver.

Then the FOG Server is trying to mount /images itself as an NFS Share when the client machines try to do anything.

This is not allowed (as stated many times, and confirmed with the “permission denied”).