Unable to mount - Value too large for defined data type

Help and Support
1

I have been successfully using rclone on my mac and I am now migrating it over to a dedicated linux box to be used as a NAS.

I am trying to run a command to mount it and verify it is working before i turn it into a system service. When I run the command it fails, saying "most helper error: fusermount: failed to access mount point: /path/to/mountpoint: Value too large for defined data type.

I trying searching online, but couldn’t find anything on it, so I am coming here for any help.

I am also running the command as root to eliminate any permissions issues. once working i will verify it functions with my user account.

Here is the detailed logs
2019/04/24 21:58:13 DEBUG : rclone: Version “v1.47.0” starting with parameters ["/usr/bin/rclone" “mount” “gcrypt:” “/srv/dev-disk-by-label-WDred/GD” “–allow-other” “–dir-cache-time” “96h” “–drive-chunk-size” “32M” “–log-level” “DEBUG” “–log-file” “/opt/rclone/logs/rclone.log” “–config” “/opt/rclone/rclone.conf” “–umask” “002” “–timeout” “1h” “–rc”]
2019/04/24 21:58:13 NOTICE: Serving remote control on http://127.0.0.1:5572/
2019/04/24 21:58:13 DEBUG : Using config file from “/opt/rclone/rclone.conf”
2019/04/24 21:58:14 DEBUG : Encrypted drive ‘gcrypt:’: Mounting on “/srv/dev-disk-by-label-WDred/GD”
2019/04/24 21:58:14 mount helper error: fusermount: failed to access mountpoint /srv/dev-disk-by-label-WDred/GD: Value too large for defined data type
2019/04/24 21:58:14 Fatal error: failed to mount FUSE fs: fusermount: exit status 1

2

Some tips I found while searching…

That suggests your linux box is 32 bit - is that correct?

Are you mounting with NFS? If so you could try NFS v2?

Can you tell us more about your linux system? OS, processor etc.

Maybe you are using a 32 rclone binary on a 64 bit system? (Which depending on the system will work but may give strange problems like this).

3

I am using an ODROID HC2 single board computer. It is a 32 bit computer. I am also using a 32 bit OS. My OS is based on Debian, it is OMV 4.1.22. Processor is ARMv71.

The HDD that is referenced in the script is formatted as XFS

I used this command to install rclone v
sudo curl -sLO https://downloads.rclone.org/rclone-current-linux-arm.deb && sudo dpkg -i rclone-current-linux-arm.deb

4

Forgot the version of rclone…

rclone v1.47.0

  • os/arch: linux/arm
  • go version: go1.12.4
5

What does:

uname -a
Linux gemini 5.0.9-arch1-1-ARCH #1 SMP PREEMPT Sat Apr 20 15:00:46 UTC 2019 x86_64 GNU/Linux

show?

6

This seems very similar to: https://www.raspberrypi.org/forums/viewtopic.php?t=206127

Which indicates compiling with large file support is needed.

I’m pretty sure the error is coming from fusermount so I think you need a fusermount compiled with large file support.

Can you run any other FUSE file systems?

Does fusermount -u nonexistent give the same error?

Could you run strace -f rclone mount... on the rclone command. I’m interested in which syscall generated the EOVERFLOW error.

7 
uname -a

Linux odroidxu4 4.14.94-odroidxu4 #14 SMP PREEMPT Fri Feb 8 11:14:13 CET 2019 armv7l GNU/Linux
8

I agree, it does seem like fusermount. I tried looking there, but couldn’t find anything that worked. I also tried to eliminate just fusermount, but it doesn’t see you can use it directly to mount something.

Here is the unmount commnand

fusermount -u nonexistent
fusermount: failed to unmount /root/nonexistent: No such file or directory

I will install strace and try it out.

9

I ran it and it generate a 44MB file. I searched for EOVERFLOW and did not find it in the output.

10

Is there a quick and easy one I can try?

11

sshfs, fuse-zip come to mind.

12

So I used fuse-zip and received the same error.

13

OK, so that means that this isn’t an rclone problem, but a problem with your install which is what I thinking.

It is will be in numeric form too… 75 is the number you are looking for. It will probably be negative so something in the strace will say = -75

I’d expect to see something like this

statfs("/selinux", 0x7ffd2538cce0)      = -1 ENOENT (No such file or directory)

Could you gzip the strace and share it with me? nick@craig-wood.com - thanks

14

Sent the file.

After doing some more research, it looks like I might need to compile with the -D_FILE_OFFSET_BITS=64 to overcome this. I am guessing it will need to do that to the fuse repo?

15

So I went down this path and was trying to recompile Fuse 2.9.7 with the -D_FILE_OFFSET_BITS=64 when someone told me they have mergerfs working. So I tried mergerfs and it works! I can transfer a 3+ GB file in and out of the mergerfs (it also uses fuse) mount and I do not have any problems. I can also unmount and remount it without any issues.

I am now wondering if rclone needs to be recompiled with large file support? (http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Value-too-large-for-defined-data-type)

16

I can see from the strace that it isn’t rclone returning generating this error it is fusermount.

the fact that you’ve made mergerfs work probably points the finger back at rclone…

I’ve not had any reports that rclone mount doesn’t work on 32-bit. Unfortunately I don’t have any 32 bit machines left to test it on myself!

One thing you could try is building rclone from source yourself on the 32 bit machine using the command go build -tags cmount. You’ll need the FUSE development library installed as well as the go compiler.

This will build a version of rclone which uses FUSE directly. You can use this with the rclone cmount command which is identical to rclone mount. In fact you’ll have access to both. Can you try that and see if it works? If it works with cmount then that means there is a bug in the fuse library rclone uses.

17

Is there a way to pass a CFLAG (-D_FILE_OFFSET_BITS=64 ) with GO or is it not needed with this cmount method, or do I have to alter a header file of some sort?

18

You should be able to set the environment variable CGO_CFLAGS to set any flags for C compilation with go.

19

Sorry for the delayed response, life got busy…

I did the steps you mentioned, and set the CGO_CFLAGS to “-g -D_FILE_OFFSET_BITS=64”

After building I ran this command
./rclone cmount gcrypt: /srv/dev-disk-by-label-WDred/GD --allow-other --dir-cache-time 96h --drive-chunk-size 32M --log-level DEBUG --log-file /opt/rclone/logs/rclone.log --config /opt/rclone/rclone.conf --umask 002 --timeout 1h --rc --debug-fuse --allow-non-empty

Here are the results

2019/05/01 16:46:01 DEBUG : rclone: Version "v1.47.0-DEV" starting with parameters ["./rclone" "cmount" "gcrypt:" "/srv/dev-disk-by-label-WDred/GD" "--allow-other" "--dir-cache-time" "96h" "--drive-chunk-size" "32M" "--log-level" "DEBUG" "--log-file" "/opt/rclone/logs/rclone.log" "--config" "/opt/rclone/rclone.conf" "--umask" "002" "--timeout" "1h" "--rc" "--debug-fuse" "--allow-non-empty"]
2019/05/01 16:46:01 NOTICE: Serving remote control on http://127.0.0.1:5572/
2019/05/01 16:46:01 DEBUG : Using config file from "/opt/rclone/rclone.conf"
2019/05/01 16:46:04 DEBUG : Encrypted drive 'gcrypt:': Mounting on "/srv/dev-disk-by-label-WDred/GD"
2019/05/01 16:46:04 DEBUG : Adding path "vfs/forget" to remote control registry
2019/05/01 16:46:04 DEBUG : Adding path "vfs/refresh" to remote control registry
2019/05/01 16:46:04 DEBUG : Adding path "vfs/poll-interval" to remote control registry
2019/05/01 16:46:04 DEBUG : Encrypted drive 'gcrypt:': Mounting with options: ["-o" "fsname=gcrypt:" "-o" "subtype=rclone" "-o" "max_readahead=131072" "-o" "attr_timeout=1" "-o" "atomic_o_trunc" "-o" "debug" "-o" "nonempty" "-o" "allow_other"]
FUSE library version: 2.9.7
nullpath_ok: 0
nopath: 0
utime_omit_ok: 0
unique: 1, opcode: INIT (26), nodeid: 0, insize: 56, pid: 0
INIT: 7.26
flags=0x001ffffb
max_readahead=0x00020000
2019/05/01 16:46:04 DEBUG : Encrypted drive 'gcrypt:': Init: 
2019/05/01 16:46:04 DEBUG : Encrypted drive 'gcrypt:': >Init: 
   INIT: 7.19
   flags=0x00000019
   max_readahead=0x00020000
   max_write=0x00020000
   max_background=0
   congestion_threshold=0
   unique: 1, success, outsize: 40

It appears to be working now, at least I can see the folders. I have yet to try and play anything from it. Can I use cmount now, or should I wait?

20

Great! Yes you can use cmount - it is the version of mount used on Windows so has had lots of testing.

So I think this must be a bug in the bazil/fuse library failing to adapt to your system somehow. Looking at the issues the library works on 386 I think, so it must be some adaption which is going wrong…