Categories

• Technical Help

  Get help with your FOG system.

  FOG Problems Hardware Compatibility Windows Problems Linux Problems Mac Problems General Problems
  13k Topics

  115k Posts

  T

  @DiegoP I feel like we don’t have enough context.

  We have many people using NVME drives, yours appears (from the lsblk output) to be a RAID mode?

  Maybe that’s part of why you’re running into issues?

• Announcements

  Get the latest news on what's happening.

  Security Advisories
  184 Topics

  825 Posts

  A

  @Tom-Elliott I really appreciate that you are putting effort into providing more frequent releases, which makes it easier for everyone to deploy new security fixes in time. Keep up the good work!

• General Topics

  View tutorials or talk about FOG in general.

  General Tutorials
  2k Topics

  19k Posts

  V

  UPDATE 07/17/2026

  After some experimentation and examining the fogftp.class.php file, I found that FOG calls ftp_rename to move files from the /image/dev/<mac_host> folder to the /image/<image_name> folder.

  Finally, it helped me to connect with a regular ftp client (WinSCP) and try to move the folders manually. This is how I found out that the problem was in the permissions set on the folders.

  So I found out that from my original version 1.5.10.10 to the current 1.5.10.1903 there was a change in the file

  /lib/reg-task/taskqueue.class.php

  in the private function _moveUpload() method it was previously

  ->chmod(0777, $dest) and now it is ->chmod(0775, $dest)

  That (maybe) could be the reason why it stopped working for me. Thanks to this post https://forums.fogproject.org/post/156271

  chown -R fog:users /volume1/images/ #set inheritance to the dev folder chmod g+s /volume1/images/dev/

  I connected to the NAS with ssh and fixed the permissions over the folders. Now it’s working fine again.

• Developers

  Report bugs, request features, or get the latest progress.

  General Feature Request Bug Reports
  2k Topics

  21k Posts

  T

  @Valer Thanks for the report and the writeup, that’s a good catch. You’re right about the cause. Debian 13 dropped the sysv-rc-conf package since it’s fully on systemd now, so the installer chokes trying to apt-get it. We never actually use that tool on a systemd system anyway, it only ever got called on the old non-systemd paths, so it was just dead weight on Trixie.

  I pushed a fix to working-1.6. It leaves the package off the list on Debian 13 and up, and it also strips it out of a cached .fogsettings so an in-place upgrade doesn’t drag it back in. Older Debian keeps installing it like before so nothing changes there.

  If you want to get moving before you pull the update, you can either grab the latest working-1.6 and rerun the installer, or just open /opt/fog/.fogsettings and delete sysv-rc-conf from the packages line, then run the installer again. Either one gets you past it.

  Let me know if you hit anything else on Trixie.