@MaMu https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1501189

That appears to be your issue, it’s a bug in dnsmasq/resolvconf where it changes your resolvconf to use 127.0.0.1 as DNS when using port 0 which of course breaks your DNS to external websites. Well, I say bug, but really that’s it’s intended function since they think you don’t want any DNS at all when using port=0.

You can try his suggestion of

Sample implementation code, to be inserted before if [ -x /sbin/resolvconf ]: (in the file /etc/init.d/dnsmasq)

    grep -qr port=0 /etc/dnsmasq.d/ /etc/dnsmasq.conf && return

Which should check if port=0 is defined anywhere and if true will ignore the following part so it doesn’t alter your nameservers in resolvconf.

@MaMu https://wiki.fogproject.org/wiki/index.php/Using_FOG_with_an_unmodifiable_DHCP_server/_Using_FOG_with_no_DHCP_server#Additional_Steps_for_12.04.4.2C_12.04.5.2C_14.04.2C_14.10

Did you modify the networkmanager.conf as well?

@Tom-Elliott Not sure why that would matter for quick image?

The issue isn’t present on revision 5240 (7190 on github probably?) anyway. (I installed this slightly older revision since I needed quick image)

@Tom-Elliott Quick image now immediatly picks the top image and starts pushing it. It loads boot.php twice upon chosing the option.

Tom found the issue.

When I was troubleshooting when I originally made the file, I used a FTP client to verify everything was in order. This in turn created .listing files in the image folders. There was no need to delete hidden files, so FOG wasn’t programmed to do so… until now! The hidden files then meant that rmdir would fail because the folders contained files.

But thanks to Tom’s awesome work it should now work every time

@Wayne-Workman I can manually connect to the FTP by copy pasting the password from any location.

Permissions are 777 (set by chmod -R 777), ownership is fog:fog (chown -R fog:fog) and have been for a while now.

Running Ubuntu, so Selinux is not even installed at all.

I believe Tom checked those things as well when we had join.me session.

I double checked everything multiple times to make sure the issue wasn’t on my side, but I’ll explore some more out there ideas now. Will report back if I have some progress.

This is what I get with latest update, not sure if this happens before the FTP move (since the images aren’t moved yet)

Most likely these are partially (or fully captured that were unable to move) capture images hanging out in /images/dev

@ITSolutions NFS is restricted to certain versions of Windows I believe

@Wayne-Workman Yes.

I did notice that in the prep stages of the capture it sets permissions for /images/macaddress rather than /images/nameofimage ,not sure if that’s relevant or not though.

On latest trunk I get the same error as https://forums.fogproject.org/topic/7153/unable-to-upload-image-error-returned-type-2-file-var-www-fog-lib-fog-fogftp-class-php/2

Obviously, deleting the folders prior to capture each time would get tedious after a while, so I’m hoping for a better solution.

@Sebastian-Roth Well, it’s definitely in ext4, so I’ll try to up the FTP timeout and see if that helps.

@Sebastian-Roth

/dev/mapper/ubuntu--vg-root on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)

I haven’t had the time to test it properly since yesterday, Tom was pretty busy yesterday as well, but from a quick test it did seem to be able to move the images (if the target directory didn’t already exist)

@Arrowhead-IT That’s because Audit mode is triggered by sysprep which only runs if the apps make it past the checks, it’s stupid, but hey.

As far as I know, the database gets updated automatically.

You may want to take a backup just in case though.

@Wayne-Workman Ubuntu, and yes all disabled. Don’t worry though, Tom nearly has it all sorted, should be ok tomorrow.

@Tom-Elliott

root@foghost:/var/log/fog# ls -la /images/dev
totaal 16
drwxrwxrwx  4 fog  root 4096 apr 11 14:47 .
drwxrwxrwx 24 fog  root 4096 mrt 15 15:00 ..
drwxrwxrwx  2 root root 4096 apr 11 14:46 08002710d395
drwxrwxrwx  2 root root 4096 apr 11 14:48 0800276fc5ee
-rwxrwxrwx  1 fog  root    0 mrt  2 17:05 .mntcheck

So, I guess it’s not a permission issue then. Same permissions for /images

Also I found the vsftpd log, it was named xferlog (after some googling this is merely a transfer log?)

Mon Apr 11 14:46:45 2016 1 192.168.1.154 0 /images/W7PRO64FR b _ i r fog ftp 0 * i
Mon Apr 11 15:07:29 2016 1 192.168.1.154 0 /images/W7HPR64NL b _ i r fog ftp 0 * i

This is the log of the images of just now.

@Tom-Elliott The log thing is definitely fixed, but it seems it still doesn’t move images. I noticed that it by default assigns root:root as ownership of the folders in /images/dev, could this be the problem?

@Tom-Elliott There is no vsftpd logfile! Most strange, since it’s definitely enabled in /etc/vsftp.conf

However, there is this when I check the status of the service: (I’ve been trying to upload images the past few hours)

apr 11 10:51:38 foghost systemd[1]: Started vsftpd FTP server.
apr 11 10:59:04 foghost vsftpd[10206]: pam_unix(vsftpd:auth): authentication failure; logname= uid=0 euid=0 tty=ftp ruser=fog rhost=192.168.1.154  user=fog
apr 11 11:55:12 foghost vsftpd[11194]: pam_unix(vsftpd:auth): check pass; user unknown
apr 11 11:55:12 foghost vsftpd[11194]: pam_unix(vsftpd:auth): authentication failure; logname= uid=0 euid=0 tty=ftp ruser=anonymous rhost=192.168.1.31
apr 11 11:55:32 foghost vsftpd[11196]: pam_unix(vsftpd:auth): authentication failure; logname= uid=0 euid=0 tty=ftp ruser=fog rhost=192.168.1.31  user=fog
apr 11 11:55:40 foghost vsftpd[11199]: pam_unix(vsftpd:auth): authentication failure; logname= uid=0 euid=0 tty=ftp ruser=fog rhost=192.168.1.31  user=fog
apr 11 11:56:23 foghost vsftpd[11212]: pam_unix(vsftpd:auth): check pass; user unknown
apr 11 11:56:23 foghost vsftpd[11212]: pam_unix(vsftpd:auth): authentication failure; logname= uid=0 euid=0 tty=ftp ruser=anonymous rhost=192.168.1.31
apr 11 11:56:26 foghost vsftpd[11214]: pam_unix(vsftpd:auth): authentication failure; logname= uid=0 euid=0 tty=ftp ruser=fog rhost=192.168.1.31  user=fog

So clearly it passes along the wrong password for some reason, but I can’t figure out why.

@Tom-Elliott The password is correct in the database.