# COPY TO fails ~ possibly file size limit reached?

**URL:** <https://community.cratedb.com/t/copy-to-fails-possibly-file-size-limit-reached/1599>\
**Category:** CrateDB\
**Created:** [September 21, 2023, 1:08pm UTC](https://community.cratedb.com/t/copy-to-fails-possibly-file-size-limit-reached/1599 "2023-09-21T13:08:13Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![sblechmann](https://avatars.discourse-cdn.com/v4/letter/s/b4bc9f/32.png) [@sblechmann](https://community.cratedb.com/u/sblechmann)\
**Post date:** [September 21, 2023, 1:08pm UTC](https://community.cratedb.com/t/copy-to-fails-possibly-file-size-limit-reached/1599/1 "2023-09-21T13:08:13Z")

</div>

Hey there,

I could not find an issue with the similar fault behaviour.

So I am using a crate cluster with 2 data nodes and 1 arbiter node, all running in docker containers. I want to copy data from some tables using the COPY TO statement to my local file system.  
It works fine for small tables: All data is stored in my files (4 shards → 4 files).  
Yet, for bigger tables, the process fails.

```auto
COPY ****
WHERE ***
TO directory ' *****' with (compression='gzip');

```

The error message is not very helpful as it gives

```auto
Fehler!

[object Object]

```

I can see that in fact some data has been copied to my file system as I got 4 files with approx. 5 MB each… So I was wondering if this has to do with some limitation of the COPY TO process related to the file size?

I’d be happy if anyone had any suggestion - thanks a lot 🙂

---

<div class="post-metadata">

**Author:** ![hammerhead](https://sea2.discourse-cdn.com/flex020/user_avatar/community.cratedb.com/hammerhead/32/270_2.png) [@hammerhead](https://community.cratedb.com/u/hammerhead)\
**Post date:** [September 21, 2023, 1:44pm UTC](https://community.cratedb.com/t/copy-to-fails-possibly-file-size-limit-reached/1599/2 "2023-09-21T13:44:35Z")

</div>

Hi @sblechmann,

can you share the CrateDB version this is happening on, please? There used to be a bug that `[object Object]` was shown instead of the proper error message in an older version.

---

<div class="post-metadata">

**Author:** ![sblechmann](https://avatars.discourse-cdn.com/v4/letter/s/b4bc9f/32.png) [@sblechmann](https://community.cratedb.com/u/sblechmann)\
**Post date:** [September 21, 2023, 1:59pm UTC](https://community.cratedb.com/t/copy-to-fails-possibly-file-size-limit-reached/1599/3 "2023-09-21T13:59:21Z")

</div>

hey @hammerhead  
sure thing, it’s on version 4.6.6

---

<div class="post-metadata">

**Author:** ![hammerhead](https://sea2.discourse-cdn.com/flex020/user_avatar/community.cratedb.com/hammerhead/32/270_2.png) [@hammerhead](https://community.cratedb.com/u/hammerhead)\
**Post date:** [September 21, 2023, 2:38pm UTC](https://community.cratedb.com/t/copy-to-fails-possibly-file-size-limit-reached/1599/4 "2023-09-21T14:38:40Z")

</div>

I can’t find the exact version number right now when the issue with the error message was addressed, but there were several reports of it around CrateDB 4.6 versions.

Is upgrading to a more recent CrateDB version possible for you? The later the better, but CrateDB 4.8.4 should be enough for this particular issue.

Alternatively, do you get a proper error message when trying to run the `COPY TO` through another tool, such as [crash](https://cratedb.com/docs/crate/crash/en/latest/). It might be only the Admin UI being affected by that bug, obfuscating the error message. You might also check if you can see the error in `sys.jobs_log`: `SELECT * FROM sys.jobs_log WHERE error IS NOT NULL`.

---

<div class="post-metadata">

**Author:** ![sblechmann](https://avatars.discourse-cdn.com/v4/letter/s/b4bc9f/32.png) [@sblechmann](https://community.cratedb.com/u/sblechmann)\
**Post date:** [February 6, 2024, 4:53pm UTC](https://community.cratedb.com/t/copy-to-fails-possibly-file-size-limit-reached/1599/5 "2024-02-06T16:53:01Z")

</div>

Hey @hammerhead, wow… it’s been quite some time since I took a look here, I deeply apologize!  
I just updated to 4.8.4, the error and the error message are the same … yet, now each file is about 112M big.  
With the `sys.jobs_log: SELECT * FROM sys.jobs_log WHERE error IS NOT NULL` I do not see anything.

I’ll have a look at this crash.