Mounting /images/dev Permission Denied
-
@vkenny If you consider what you are doing in the windows realm is this.
You have 2 servers. On the first server you have a share, lets call it \server02\somefiiles You connect that share to server01 as the w: drive. Now you are trying to reshare the w: drive on server01. In windows this is not allowed same with linux.
For the fog server’s proper operation there is a customized linux operating system that runs on the target computer. It connects to the fog server using NFS. It actually mounts /images/dev to upload the image. This share information is visible when you cat’d
/etc/exports. These are the nfs exports from the FOG server.If you look at your exports file
/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)You are sharing /images and /images/dev. The /images share is configured for read-only at a share level permission. Where /images/dev is shared as read-write.
This is perfect, what fog expects and what is required.
Now what you have done below this is you are using the /images directory as a mount point (not a directory) for an external nfs share (from your windows box). i.e. creating the reshare of an nfs mounted external share.
-
@vkenny said in Mounting /images/dev Permission Denied:
Its simply an NFS share from my Windows server to the FOG server.
Right but the FOS engine (customized linux that runs on the target computer) mounts the NFS share on the FOG server to upload the disk image.
So to the question how can I do what I want?
- Setup your windows server as a FOG storage node like I first posted with the link.
- Install an iSCSI software to share out a iSCSI block device and mount that on your fog server. I think starwinds has a free iscsi target software (up to 1TB) that you can install on your windows server.
- While I don’t really like this idea at all, I have heard of some people attaching a usb hard drive to their esxi server and passing that usb hard drive through to the FOG server for storage.
Understand what we are talking about is not a FOG issue, but rather a NFS issue. You would have the same issue if you had a nfs file server setup. Its not FOG that placed these requirements on the nfs file shares.
-
Similarly,
It doesn’t matter where the share is coming from.
You can share an mount point no matter how it’s being requested.
For example:
If you only have the windows share, (this is the first share), and you mount it directly on the client, you will have success. You can have other systems mount this share as many number of times as needed.
Now let’s place this in the realm of FOG server.
You have mounted the windows share to /images. This is perfectly fine.
Now you’re sharing the same already mounted share to another system.
/FOG-Share is mounted to /images. The client machine loads and tries to mount the /images mount to the client. This is the double share. You’re using a proxy trying to mount the system as it’s already been mounted.
-
@vkenny said in Mounting /images/dev Permission Denied:
So if I make my /etc/fstab look like this:
$ 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 /FOG-Share nfs _netdev,defaults,user,auto,noatime,intr 0 0
169.254.91.1:/FOG-Share /images nfs _netdev,defaults,user,auto,noatime,intr 0 0then complete the necessary steps to change the storage node, this should work?
Or if not what should I do? -
@vkenny No.
You cannot reshare an nfs share.
What we’re trying to tell you, no amount of “sharing” is going to fix this for you. You could try another mounting option. Maybe CIFS/Samba from the windows share. Mounted via CIFS then the nfs side should work, but this is still fragile. -
ok, so I’m sorry this is confusing me, I’m just not grasping the direction you are providing. Sometimes I need to be told like I’m 5 yrs old… What it sounds like to me that you are saying is that I cannot use an NFS Share as a repository for images which I know is not the case…
If you could give me a few directions to follow I would be very grateful.
I also have to say the almost instant turn around in responses is exceptional. Thank you very much for such a solid support system. You guys rock!
-
@vkenny You cannot use an nfs share to mount and then re-export it as an nfs share.
This is what you’re currently doing.
-
Right. After 50 times of telling me I understand what you are saying. Problem is I’m now at a stand still because I don’t know a solution. Is there something else I can do to use this NFS Share as an image repo?
-
@vkenny I just told you how.
Share the volume, not as NFS, but as a windows “Share”
Mount that share via fstab using cifs or samba (whatever it’s called).
-
@vkenny Well lets start in the beginning…
The target computer must connect to the FOG server over NFS. That must happen.
The fog server in YOUR setup is connecting to an external NFS share. So this is resharing an nfs mounted share.
As Tom said, you could install SAMBA on your FOG server and then connect to your windows server over CIFS (windows share technology). Then it might work ( I say might because I have not personally done this. ).
As I posted before you could use iSCSI and connect your fog server to an iscsi target software running on your windows server.
-OR- you can setup your windows server as a FOG storage node. Then the FOS engine will connect to your windows server over NFS (that you already setup) and not have to talk to the fog server at all.
-
@george1421 said in Mounting /images/dev Permission Denied:
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
Without intending to sound self righteous, my first post outlined what you “could” do to use your windows server as a fog storage node.
-
alright. so I mounted the Windows share as cifs. I can add and remove directories to the mounted share with no issues. I made and deleted directories to assure I was connected.
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 cifs username=fog_user,password=ThePasswordForFog_User,_netdev,defaults,user,auto,intr 0 0then I ran the fogsetup script again and received this:
-
You still need to install/update your database schema.
-
This can be done by opening a web browser and going to:
-
Press [Enter] key when database is updated/installed.
-
Setting up storage…Failed!
any ideas?
-
-
@george1421 it says at the end of the comments you are at a stand still. Does this work?
ref: https://forums.fogproject.org/topic/6941/windows-server-as-fog-storage-node-proof-of-concept-blog -
@vkenny The standstill was getting the web pages to display correctly. But that is not needed for imaging function, just for reporting to the FOG console. The imaging part should work.
Just understand that was a proof of concept document that was written quite a while ago with a different version of FOG. Will it work today??
-
@george1421
since I’m so close at this point, do you have any ideas on my previous post before I burn everything down and start over with your proof of concept… -
@vkenny What’s in the installers error log in regards to the setting up storage failed.
-
error log:
chmod: changing permissions of ‘/images’: Permission denied
chown: changing ownership of ‘/images’: Permission denied -
@vkenny This might be because of how you’re sharing. You haven’t done anything wrong, but it’s shared from another element.
Try running the installer with the
-Xargument. -
ran it with -X and it bypassed the storage setup which indicates failed when script is running. The /images directory still does not have the correct permissions.
what’s more is when I try to chmod or chown the /images directory I get permission denied even though I’m root, and the user used to mount cifs in fstab is in the administrators group in windows with full control.
-
@vkenny THis is because it’s shared from a windows source. Permissions must be set at the windows side, not the linux side.
