FOG 1.2.0 multicast issues
-
There shouldn’t be,
THe listing only becomes active once the command is started. (Task such and such started) from the logs.
Once the cmd is started, it places the multicast task into a “queued/in-progress”. In your case, it probably doesn’t get seen because right after it starts it closes the task as “complete”
-
exports file:
/images *(ro,sync,no_wdelay,insecure_locks,no_root_squash ,insecure)
/images/dev *(rw,sync,no_wdelay,no_root_squash,insecure) -
Since it looks like /images is read-only in the exports file should I edit that file for rw or is there a different way of changing it? Or is it not necessary?
-
is that from fog server or the box where /images is moutned from?
-
That is from the box where the images are stored.
-
Okay,
I’d say copy the exports from there to your FOG Server, if they don’t match already.
In that exports only set:
[code]*(rw,sync,no_wdelay,no_root_squash,insecure)[/code] -
Then restart the NFS services on both the hosting images box and the fog server.
[code]sudo service nfs-kernel-server restart[/code]
-
They both match. Which should I change, fog server or image box?
-
The image box.
-
done. restarted nfs kernel servers and FOGMulticastManager and still not working
-
Then I’m at a loss as to what this issue is.
One last thing to try if at all possible:
[code]umount /images
touch /images/.mntcheck
touch /images/dev/.mntcheck
scp -r 10.1.0.56:/images/PeteTest /images/
chown -R root:root /images
chmod -R 777 /images[/code]If you have enough room of course. Then try redoing the tasking, does all work?
-
touch: cannot touch `/images/dev/.mntcheck’: No such file or directory
-
mkdir /images/dev
touch /images/dev/.mntcheck -
This says it will take about 18 minutes. I will leave it running but I have to leave the office now. I really appreciate your help with this and will report back in the morning with a status.
Thank you very much.
-
okay, thank you,
-
Unfortunately, we did run out of space on this so we can’t test on the one server. Do you think permissions would be an issue since unicast imaging does work?
-
Yes.
Unicast access the file system on /images as root user.
This means that it’s the same permissions as if it were on the nfs.
The Multicast tasks, initially, get started from the www-data user. So if permissions are read only, it can’t execute anything on them.
-
Would it make sense to change the owner of PeteTest to www-data for testing purposes?
-
No,
Because the /images directory is still mounted read only.
-
Also, why wouldn’t I change the /etc/exports folder on the fog server to match the image box:?
/images *(rw,sync,no_wdelay,no_root_squash,insecure)
/images/dev *(rw,sync,no_wdelay,no_root_squash,insecure)
