FOGFTP Faile to rename file.
-
I’m running FOG Trunk version 5864 (which I’m sure is a bit outdated, but it’s been working really well for the most part).
Recently, I had to add a hard drive to my fog server for storing images. I don’t use storage nodes - this is all on one single server. I added a hard drive, formatted it, and mounted it as /images. All my images are stored there no problem, but whenever I upload an image, I get this error message:
FOGFTP: Failed to rename file. Remote Path: /images/[image name], Local Path: /images/dev/[mac address], Error: ftp_rename(): Permission Denied.
I’ve done a recursive chmod to change permissions on /images to 777 and also used chgrp and chown to change ownership to “fog.” Not sure what else I can try to get these permissions to work.
My current workaround is to log into the server manually and do this command:
sudo mv /images/dev/[mac address] /images/[image name]This solves my problem, but I’d like the upload to work on its own. :S
Any ideas?
-
Read through this:
https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_FTP -
https://wiki.fogproject.org/Troubleshoot_FTP
Also, try updating. There may be some quirks, but edit the /opt/fog/.fogsettings and make sure the
password='somepasshere'is set to what you expect it to be. Newer versions of Trunk auto set the password every install so as to help limit issues down the road. -
2 answers in under 2 minutes, from a moderator and a senior developer - for free. Can Microsoft do that? Nope. Takes them 2 days to respond to a paid support email.
-
Thank you both for the advice! I checked under .fogsettings and saw that the password was randomly generated, so it was not what I was expecting. I updated that and am doing a test upload now. Will report back with results!
-
@kenneth.sisco If that’s all you did, then it probably won’t work still. You need to follow all the steps in that article for credentials.
-
I feel like I may have made this worse. Now, my upload stops at this point. If I look under /images/dev/[mac address], I do still see all the files there, but the task on the client just gets stuck here.
The change that I made was to /opt/fog/.fogsettings, and I changed two lines. I still have the default password of “password” for the “fog” account. These two lines were changed:
password=‘password’;
storageftppass=‘password’;Before, these two lines showed what appeared to be randomly-generated passwords within the quotes. Did I do something wrong?
-
@Wayne-Workman Good catch - I need to read the manual!
I’ll go through and update everywhere as it states, then try again. Thank you!
-
I updated the credentials in the following locations:
Web Interface -> Storage Management -> Default Member -> Management Username & Management Password
Web Interface -> FOG Configuration -> FOG Settings -> TFTP Server -> FOG_TFTP_FTP_USERNAME & FOG_TFTP_FTP_PASSWORD
/opt/fog/.fogsettings - “password” line and “storageftppass” line.
Local fog user’s password (passwd command).I rebooted the server after doing the above, then double-checked all locations to be sure nothing changed. Tried uploading again, and I get the same as the screenshot in my previous post here. It gets hung after “Stopping FOG Status Reporter.”
The image files are still located on the server under /images/dev/[mac address], so they’re being uploaded, but I definitely made this worse haha.
Is there a log file that I can check to get more detail?
-
@kenneth-sisco Have you tried to connect via a normal FTP client to see if the credentials are correct?? See in the troubleshooting guide Tom and Wayne posted.
-
@Sebastian-Roth Yes, I have. I went ahead and did it again just to be safe. Using WinSCP, I can connect via FTP to the server using the standard fog credentials and traverse all directories no problem.
-
@kenneth-sisco Well then please post the output of
mounthere in the forum. I have another idea what’s causing this. -
@Sebastian-Roth Here you are!
'/dev/sda1 on / type ext4 (rw,errors=remount-ro) proc on /proc type proc (rw,noexec,nosuid,nodev) sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) none on /sys/fs/cgroup type tmpfs (rw) none on /sys/fs/fuse/connections type fusectl (rw) none on /sys/kernel/debug type debugfs (rw) none on /sys/kernel/security type securityfs (rw) udev on /dev type devtmpfs (rw,mode=0755) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620) tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755) none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880) none on /run/shm type tmpfs (rw,nosuid,nodev) none on /run/user type tmpfs (rw,noexec,nosuid,nodev,size=104857600,mode=0755) none on /sys/fs/pstore type pstore (rw) /dev/sdb on /images type ext3 (rw) systemd on /sys/fs/cgroup/systemd type cgroup (rw,noexec,nosuid,nodev,none,name=systemd) rpc_pipefs on /run/rpc_pipefs type rpc_pipefs (rw) nfsd on /proc/fs/nfsd type nfsd (rw) -
@kenneth-sisco So you have /images formated with
ext3as I see.Read this:
Learned something new … (pretty much every day!)
ext3 does some kind of defragmentation/reallocation foooo when files are being deleted!
http://www.depesz.com/2010/04/04/how-to-remove-backups/
I (re)moved all my images, re-formated with ext4, put it all back together and now everything seems fine. Deleting of 150GB image takes less than 10 seconds. Awesome!!! I really wonder why very little people have issues with this. Is ext3 not in use in most recent distributions??As well interesting that you formated the whole disk (sdb). Usually people create one single full size partition on a hard drive (e.g. sdb1) before formating it.
-
Updated to the latest trunk release on the SVN and had to run the SQL commands listed here:
https://forums.fogproject.org/topic/7734/snapin-id-was-not-set-or-unable-to-be-created-svn-revision-5661/27After that, it started working great.
Thanks for the help, guys!
