Clonezilla / Bugs / #396 "No space left on the device" error when image is just starting to be saved

Dan Bielaski - 2022-12-06

So, like Marty McFly I went 'back in time' (with Clonezilla Live versions, at least) to see if I could
gather more diagnostic data and see when this defect might have been initially introduced.

I downloaded the versions available from https://sourceforge.net/projects/clonezilla/files/clonezilla_live_alternative/ that started immediately after the version I had last downloaded, and still used, which again is clonezilla-live-20201102-groovy-amd64. Here is what I found with my testing...again, all Clonezilla executions were given the exact same input variables / parameters:

20210127-groovy: Worked perfectly - no problems encountered
20210530-hirsute: Worked perfectly - no problems encountered
20210609-hirsute: Worked perfectly - no problems encountered

20210817-hirsute: This version would NOT boot properly. The exact same problem as described in https://sourceforge.net/p/clonezilla/discussion/Help/thread/8a05f2d88b/ was encountered (Failed to open \EFI\BOOT\? - Invalid Parameter, etc). I tried both the ISO and ZIP versions and got the same error with both, so I had to skip this Clonezilla Live version.

20211116-impish: Starting with this version, the error I reported with my original post ("No space left on the device...") occurs right when the image starts to be saved. I checked a few of the other recent versions (20220620-jammy and, of course, 20221103-kinetic), and all issue the exact same error at the exact same point in the execution.

I am hoping this additional information will be helpful to the development team. For now, I will have to stay at the 20210609-hirsute version, at least for network-based execution, as it is the
last Live version before the defect was introduced. I am fortunate, at least, that the 30-second
countdown issue with the wireless adapter detection was corrected by this version, so that helps
speed up the process a bit.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Steven Shiau - 2022-12-10

I can not reproduce this issue here. I uses Clonezilla live 20221103-kinetic here, and Windows 10 as the CIFS image repository.
Attached you can find the log file. It ran smoothly.
Maybe the CIFS default parameters when mounting have changed? You'd better to check if you have to tune that.

Steven

log-cifs.txt

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Dan Bielaski - 2022-12-10

Interesting - can you at least reproduce the UEFI boot error with the 20210817-hirsute image?

I went through the process using the last 'hirsute' version that works properly (20210609) and
compared the generated OCS-SR command with the one that fails (attached previously). I'm
attaching a photo of this as well...the only real difference I notice is the -i parameter...it is coded to "4096" in the 20210609 (and earlier) versions, and the later versions have it as "0" (again, refer to the original photo that was posted).

Could that be involved? Again, permissions don't seem to be the problem as the destination directory and several different (non-empty) files are generated successfully before the error
occurs, and available space for the stored image is definitely not an issue. The error occurs
right after "Checking the disk space..." is issued, but before partclone has a chance to run.

Last edit: Dan Bielaski 2022-12-10

IMG_20221210_172004.jpg

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Dan Bielaski - 2023-01-02

Seems that "feature" (i.e. default of -i 0for ocs-sr to not split the image file of a partition) was introduced with Clonezilla live 2.8.1-5 to address a fairly-rare usage case to help boost performance a little. More information is documented at https://sourceforge.net/p/clonezilla/discussion/Open_discussion/thread/46706796eb/.

Now that the holidays are over, I expect more time to be able to do a bit more testing. However,
I don't believe the -i parameter is one that can be overridden / selected using the "Advanced" screen with options running Clonezilla live. If there is an easy way to specify that (again, without having to dredge up the saved osc-sr command to be edited / executed in command shell), please post that info here. I think it would be proof of a bug if restoring the default of -i 4096 leads to successful execution (i.e. "no space left" error is not encountered).

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Dan Bielaski - 2023-01-02

Well, I just did some testing before jumping into bed, and I found the option to change the
"-i" value when selecting the "Expert" option. However, changing the value from 0 to 4096 did not circumvent the error, so I'm not so sure that is the root cause.

If I can figure out a way on a subsequent run to try and extract / save the error logs from the
Live run (logs are in RAM), that may be of some help. It seems that in the middle of running
things, Clonezilla Live is somehow losing connectivity or thinks it's losing permissions for the
"/partimag" mapping for the destination files. There are several files successfully created during the initial part of execution, such as dev-fs.list, Info-dmi.txt, Info-OS-prober.txt, etc. I think I mentioned it earlier in this bug report, but there is a file named "saving-error-202301012118" (date value in name varies) that is 0 KB (empty) and seems to possibly reflect when the connection and/or permission "breaks". Hopefully I'll be able to figure out more in the next several days, but appreciate any input or suggestions for what to check next.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Dan Bielaski - 2023-01-03

Good news to report: With some additional testing I have further narrowed in on the underlying root cause of this bug ("No space left on the device..."), and believe the results demonstrate that the error is with Clonezilla and/or one of its depedencies and not with my local environment. Since there were many different test scenarios I performed, I'll just summarize the more important findings:

After reproducing the error several times and performing some investigative commands from the shell, I began to suspect the CIFS version of the mapping may somehow be involved, which I confirmed by testing with several different versions of Clonezilla Live. Using the most current "Stable" version available, clonezilla-live-20221103-kinetic-amd64, I ran through iterations of all possible options on the "Samba protocol version" screen (keeping all other options the same), and these are the results:

1.0 - Successful 2.0 - Successful 2.1 - Fail 3.0 - Fail 3.1.1 - Fail

I then reran my execution using an older version of Clonezilla Live, 20210609-Hirsute, once again keeping all other options the same. And, those were successful, up to and including SMB version 3.1.1 (which is what the "auto" neogtiation option winds up selecting). Some other evidence that seems to indicate this is an issue with Clonezilla Live itself, in addition to the error only starting to occur sometime after 20210609-Hirsute:

Once the SMB share is mounted, the directory is created successfully and Clonezilla creates at least 8 different files successfully (totalling about 17 kB) before the error occurs as Partclone execution is ramping up.

I have 6 different Linux machines mapping to this and other CIFS shares via FSTAB, and none is having any problems whatsoever (and, none limit the SMB version, etc).

I also have other Windows and Android devices accessing these CIFS/SMB shares without issue.

If time permits, I will continue trying to pinpoint this further by digging into the Clonezilla scripts, but I feel one of the developers / maintainers might have a much easier go at it, especially in light of these new testing results. For now, I guess I'll have to regress the SMB version selection to no greater than 2.0 if I want to run a current version of Clonezilla Live. I do occasionally save the image directly to a USB-connected hard drive, but the vast majority of image creation that I do is across the network using SMB (again, hosted by a TrueNAS server running the latest version 13.0-U3.1, which is based on FreeBSD 13.1)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Steven Shiau - 2023-01-04

Thanks for your updates. How about CIFS server? Have you tried it on different type of it? Maybe there are some incompatibilities between the CIFS in Linux and FreeBSD? Some special parameters have to be put in either client or the server?

Steven

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Dan Bielaski - 2023-01-04

Thanks for the prompt reply. I don't have any other file servers defined, but TrueNAS has the ability to create other kinds of shares such as NFS, AFP, etc. Though I've never had a need to
work with anything other than SMB (CIFS), I'd be happy to set up some other shares if you think
that would help with diagnosis, though I'd probably need some guidance on what to do.

However, my concern is that though the issue is triggered by the MOUNT parameter of "vers=", the fact that the directory and many different Clonezilla files are being created successfully before
the error occurs indicates some other root cause, especially since all of my SMB shares are fully open to guest access (i.e. no restrictions). Is there some recent change (after June 2021) that could
have caused a change or loss in credentials at that point in the execution? Looking briefly through the code on Github, it seems the error comes out of OCS-FUNCTIONS ('disk_full_test' function). But, the mktemp / dd commands should not be expected to fail, no matter what version of SMB is chosen, especially since the directory was successfully created and several files added successfully to the directory before then.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Steven Shiau - 2023-01-05

I believe there are some changes in upstream (e.g, cifs-utils, and Linux kernel), but from the log file we have about mounting CIFS, we only add version, nothing else.
Because I can not reproduce this issue here in my environment, it's very difficult to address this issue. Luckily, you have found some workarounds....

Steven

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Dan Bielaski - 2023-01-05

True, but regressing the CIFS version is a bit precarious and leaves me wondering if it might break even further in the future. Since I couldn't get the "alternative stable" release of 20210817-hirsute to boot (I even since tried using VirtualBox, but that failed to boot as well), I went back and repeated my testing using the "stable" versions available. My testing showed that sometime after 2.7.3-19-amd64 and before 2.8.0-27-amd64 is when the defect was introduced, which was the roughly 3 months between 8/17/21 and 11/16/21. From what I see at the "Changelogs" web page, there are only about 12 revisions in that span of time, which significantly narrows down the list of potential suspects.

I may have checked the wrong utility, but I did a spot check of "Mount.CIFS" and found that though it changed with a later version 3 update, it was the same (ver 6.11) in the 2.7 and 2.8 versions mentioned above. I am at a loss as to why this problem wouldn't be more widely reported, but I still feel confident it is with some component of Clonezilla since all versions before 2.8.0-27-amd64 work successfully with my SMB shares (all versions of CIFS), and I even checked with commands like SMBSTATUS, MOUNT, etc. during my test execution, and the credentials, CIFS version reported, etc. all were exactly as was expected on the TrueNAS-side of things.

One other "weird" thing I observed: after the "No space left on the device error" occurred and I pressed Enter to continue, there were several more files successfully created (using the CAT command, I believe) to save various info like DMI, PCI and SMART data. Please see the attached screen capture - I also confirmed the files were actually in the destination directory as well. Could it be some other command (dd, perhaps?) is triggering the error somehow?

Oh well - I feel I've done all I can to help narrow down this bug. Even if it is some other component like kernel code or another dependency, I think it is worth pursuing still.

Clonezilla-post-error.png

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Steven Shiau - 2023-01-06

We use two methods to detect if there is any space to write. In the file "/usr/share/drbl/sbin/ocs-functions", you can find a function called "disk_full_test", it uses "mktemp" and "dd" command to test if the repository is writable or not. It's something like:
mktemp /home/partimag/$tgt_dir/diskfull-test.XXXXXX
dd if=/dev/zero of=/home/partimag/$tgt_dir/diskfull-test.XXXXXX bs=1M count=1

Maybe you can manually run that as root to test it?
Thanks.

Steven

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Dan Bielaski - 2023-01-08

I believe that is the function I referenced in my earlier post (https://sourceforge.net/p/clonezilla/bugs/396/#70a4), which I found in Github under clonezilla/scripts/sbin/ocs-functions, starting around line 1117.

I reran my testing so I could execute the disk_full_test commands manually. I ran with both Hirsute and Kinetic versions to compare results, but found the commands completed successfully (using SMB 3.1.1) in both cases. I'm attaching screen captures of the command output for each - please take a look and let me know if you see anything wrong with the process I used.

Could a change have been introduced in that 3-month window that would have led to a scenario where root priveleges are not being properly used during execution of those commands? It seems that inadedquate permissions are more likely causing the error than insufficient disk space.

Hirsute-test.jpg

Kinetic-test.jpg

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Steven Shiau - 2023-02-10

I still can not find how to reproduce this so that I can fix it. If you find that, please let us know.
Thanks.

Steven

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Dan Bielaski - 2023-02-13

I can reproduce the error without fail. If there are steps you can provide for me to run through while recreating the error which would help collect diagnostic data you are seeking, I'd be glad to do that for you.

I don't imagine there are any unique aspects of TrueNAS' implementation of SMB/CIFS, so I would imagine you might have success if you can stand up a basic installation (my guess is that in a virtual machine would be sufficient). Maybe there is something about MS Server's environment that is masking the defect (and, why more users aren't encountering it).

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Dan Bielaski - 2023-09-06

It's been awhile (life gets busy, right?), but I've got a few updates regarding this issue that may be helpful:

I downloaded the newer version of Clonezilla Live, clonezilla-live-20230426-lunar-amd64, just to see if that might incidentally fix the problem. It did not.

In the meantime, I had an old server that I repurposed that had hardware specs very similar to my TrueNAS server, but I installed OpenMediaVault (OMV) on it instead. One of the first things I did after initial install was to create an "Images" share for use with Clonezilla, and tried to configure it the same as the "Images" share on my TrueNAS server. OMV has a radically different interface for creating filesystems & shares, but I focused on the primary attributes like "Guests Only" public access and everyone with read/write access in permissions. I then ran Clonezilla and saved disk images for several machines to the OMV share, using the defaults (including "Auto" for the SMB version), and everything ran successfully - no errors.

So, the issue (as I have highlighted previously) seems to have been introduced sometime after clonezilla-live-20210609-hirsute-amd64, and also seems to involve lower-level settings (perhaps ACL at filesystem or share level, user group(s) used, etc) that somehow was being encountered within the TrueNAS configuration. As a reminder: Forcing Clonezilla to use SMB 2.0 seems to avoid the problem. I did some research on CIFS and SMB, and combed through some of the lower-level TrueNAS settings, and based on that I tried the following scenario:

I ran Clonezilla (lunar) again, and this time I chose the default (Auto) for SMB, but instead of the Guest account I used the Nobody account (as counter-intuitive as that seemed!). This allowed the image storing process to proceed farther, getting past the point when checking for available disk space. After that, the first partition was successfully stored on the TrueNAS share. But, before the next partition was saved, Clonezilla encountered the same error as originally reported ("No space left on the device or there is a permission issue..."). I am attaching the saving-error file that was generated for reference.

I'm hoping that might help shed further light on the issue. For now, I am using the OMV server share for my Clonezilla disk imaging, and use RSYNC to push them to a central machine (also done with the TrueNAS server) where all data are collectively duplicated to a secure device for off-site storage.

saving-error-202309060937

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Gerry FitzGerald - 2025-12-31

This issue "No space left on the device or there is a permission issue" still persists when selecting backup to Samba Server in December 2025 using clonezilla-live-3.3.0-33.
In my particular case I was saving to a SMB share from a QNAP TS531X.
Older clonezilla versions (e.g. 3.1) do not have this issue and work as designed to this same share.
The workaround suggested by Dan Bielaski above (i.e. using CIFS V2.0) allows the job to complete.
Alternative workaround was to share the folder from QNAP using NFSv3 which also worked.
It would be nice to see this issue addressed at some point in the future.
Still an excellent tool for the job!

Last edit: Gerry FitzGerald 2025-12-31

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Steven Shiau - 2026-01-01

"In my particular case I was saving to a SMB share from a QNAP TS531X." -> So do you know the SMB version provided by your QNAP sever?
Did you try to select different version of SAMBA when using Clonezilla live to mount your QNAS server?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Gerry FitzGerald - 2026-01-03

Thanks for your reply. If I choose a different version of SAMBA (i.e. version 2.0) then CloneZilla 3.3.0 works successfully.
My experience using CloneZilla 3.3.0 was the same as Dan Bielaski above:
version 2.0 - Successful
version 3.0 - Fail
version 3.1.1 - Fail

Using an older version of CloneZilla is also successful; for example I retried CloneZilla 3.2.0.5 earlier this week with success, choosing samba-server as the target and version was "auto".
Looking at /proc/mounts for this successful backup to my QNAP, the CloneZilla command line showed the following:
//10.21.21.21/Xdrive/GeneralStuff/Backups on /home/partimag type cifs (rw,relatime,vers=3.1.1,cache=strict,username=xxxxxx,uid=0,noforceuid,gid=0,noforcegid,addr=10.21.21.21,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,reparse=nfs,rsize=4194304,wsize=4194304,bsize=1048576,retrans=1,echo_interval=60,actimeo=1,closetimeo=1)

In summary I believe the QNAP is using SMB protocol version 3.1.1 which works successfully with CloneZilla 3.2.0.5 but is unsuccessful when using CloneZIlla 3.3.0. What is confusing is that CloneZilla 3.3.0 will successfully mount the QNAP share and successfully create the "Info-xxxxx.txt" files on the QNAP share but then just stops with " No space left on the device or there is a permission issue".
There is >1.6TB free space left on the device.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Steven Shiau - 2026-01-08

Could you please give testing Clonezilla live a try? i.e., >= 3.3.1-23 or 20260108-*:
https://clonezilla.org/downloads.php
They come with newer Linux kernel and Samba-related packages. It might work better.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Gerry FitzGerald - 2026-01-25

I have returned to test the samba-share option again today.
I have downloaded and booted my test system with 3.3.1-27 (currently the latest available).
This fails in the same way, with the same message:
No space left on the device or there is a permission issue. Therefore, data cannot be written to this directory :: /home/partimag

After the failure I pressed "Enter to continue" as prompted and clonezilla successfully completed the "Saving hardware info by lshw" to /home/partimag.
I had noticed this previously but not investigated.
Accessing the command prompt I noticed that /home/partimag was still mounted and the lshw & info.txt files are present and complete in the samba share area.
But if I attempt to create a dummy file in this directory (touch testfile) I get the following message:
touch: cannot touch 'testfile': Permission denied
The unix "id" command shows the used id is as follows:
user@cl-3.3.1-27:/home/partimag/spooky-2026-01-25-15a-img$ id
uid=1000 (user) gid=1000(user) groups=1000(user) , 24(cdrom) , 25(floppy), 27(sudo) , 29(audio) , 30(dip) , 44(video), 46(plugdev) , 100(users) , 109(netdev), 110(bluetooth)

But if I use the "sudo" command to create the testfile it is successful!
sudo touch testfile
Success. The file is created successfully in /home/partimag

In summary this looks like a permissions issue but only at a specific (critical) part when saving to a samba share. Screenshot of "touch" command operations attached FYI.

I hope this additional information is useful.

Last edit: Gerry FitzGerald 2026-01-25

Clonezilla_3_3_1-27-Screenshot 2026-01-25 162035.png

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Gerry FitzGerald - 2026-01-25

saving-error-202601251546 also attached below showing ocs-sr command being run and the error returned.

saving-error-202601251546

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Gerry FitzGerald - 2026-01-25

Temporary workaround:
Having noted the ocs-sr command that was originally launched (displayed during runtime and recorded in the previous “saving-error-202601251546” output) and having also noted that “sudo” resolved my earlier permission problem when writing to the samba share I decided to combine both. The subsequent backup and verification has completed successfully. The command was initiated from the command line as follows:
sudo /usr/sbin/ocs-sr -q2 -c -j2 -edio -z9p -i 0 -sfsck -senc -plu -p choose savedisk "spooky-2026-01-25-16b-img" sda
In summary, the inclusion of sudo at the start of the ocs-sr command has been a successful workaround for me but requires command line execution.
I look forward to a final fix in the future.

Clonezilla_3_3_1-27-Screenshot 2026-01-25 172511.png

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Steven Shiau - 2026-02-04

OK, thanks for sharing that.
If I understand correctly, so this is related to the permission which samba mapped. In that case, basically if root permission works for you, and which is also required for you to access local destination disk, you should keep using that.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Dan Bielaski - 2026-02-04

Been watching the latest updates on my thread here, and wanted to share some add'l info. Since I initially reported the problem (and, no code solution in Clonezilla was available), I have since 'worked around' the problem by standing up an SMB share on a different TrueNAS server. The "out of space" error would happen persistently when the SMB was hosted on my TrueNAS Core server (v13.3), but when I stood up an SMB share on my TrueNAS SCALE server (v25) that was defined exactly the same way (with exactly the same mapping parameters), the error did not occur. I continue to use Clonezilla alternative stable successfully with that TrueNAS SCALE setup, without having to select a specific SMB version in Clonezilla as a workaround like I used to have to do.

Of course, it would be ideal if Clonezilla code could detect whatever underlying SMB issue is causing the false "out of space" error and effect a workaround automatically, but I thought it would help others if I posted my solution as another alternative.

Last edit: Dan Bielaski 2026-02-04

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Steven Shiau - 2026-02-06

Actually it's not easy for us to know the SMB version issue since we do not have that type of NAS server here. From Dan's description, it seems the issue is due to the buggy NAS system? Or maybe some kind of SMB version mismatch?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

"No space left on the device" error when image is just starting to be saved

A partition and disk imaging/cloning program

Group

Searches

Help

#396 "No space left on the device" error when image is just starting to be saved

Discussion