Unable to copy/move files

What is the problem you are having with rclone?

I installed Rclone perfectly and tried several versions but none of them work for me. I have to say that previously it worked for me and I have had it for over a year without problems. The fact is that I mount Rclone in the folder that I specify and I get all the files, but it is impossible to copy or move files to those folders from DSM.

What is your rclone version (output from rclone version)


Which OS you are using and how many bits (eg Windows 7, 64 bit)

I have Xpenology installed for virtual Synology.
The version I have of Synology is DSM 6.2-23739 and the model is DS3617xs.

Which cloud storage system are you using? (eg Google Drive)

Google Drive only

The command you were trying to run (eg rclone copy /tmp remote:tmp)

rclone mount drive: /volume1/Ilimitado --allow-non-empty --allow-other --debug-fuse --default-permissions —log-level DEBUG --log-file /volume1/homes/admin/rclone.log &

A log from the command with the -vv flag (eg output from rclone -vv copy /tmp remote:tmp)


I'm not seeing any write attempt in the log you posted.

You can turn off debug-fuse for now as that adds quite a bit of extra stuff.

is generally very bad as it allows for multiple processes to run and you to hide things when mounting.


I have mounted it removing the parameters that you have indicated and I have copied again from the DSM, from the graphical interface the same file.

From the logs, there is still no write operation happening so not sure what to suggest as perhaps you can try from a command line or another way?

If I do it by terminal, with the command cp it seems that it works (attached log).


But I don't understand why it doesn't work from the DSM graphical interface.

Yeah, that does seem strange. Perhaps some that uses that can comment as from the logs, it doesn't even try to write from what I was looking at.

Well, let's see if anyone knows anything about it, as long as they don't hide it again.

The fact that it works with other means would lead me to think there is a quirk happening between the FUSE-mount and the DSM interface that may not be related to rclone itself. (check FUSE is up to date?)

Is this exactly the same setup as worked before except for rclone being updated? Or have you recreated a setup that worked before? What permissions are implied by --default-permissions? We should double-check there is no weird permissions quirk between whatever account is running the rclone mount and the one running the DSM manager. --allow-other should generally solve this, but I think it is worth checking as the DSM manager might be more picky for whatever reason.

"mpossible to copy or move files to those folders from DSM."
Could you elaborate on that? What exactly happens when you try? Do we have any error or unusual behavior there to give us a hint?

Not sure why your first two posts got hidden. They are still accessible though. Animosity can probably fix if it's an improper flag.

Hi, thanks for answering. I'll tell you a little more in detail.

I have followed this tutorial: https://bitbucket.org/fusebit/plex-and-google-drive/wiki/Synology

At the end, I have a folder in /volume1/homes/admin called googledrive, which before mounting Rclone has the following permissions:

bash-4.3$ ls -l
total 36
-rwxr-xr-x 1 admin users 29437 Jul 30 16:57 Copia de Libro2.xlsx
drwxr-xr-x 1 admin users    42 Nov 21 20:28 Drive
drwxr-xr-x 1 admin users     0 Nov 21 20:31 googledrive
-rwxrwxrwx 1 admin users   401 Nov 17 14:39 rclone_mountstar.sh
drwxr-xr-x 1 admin users     0 Jan  6  2019 www

Once I mount Rclone, it still has these permissions:

bash-4.3$ ls -l
total 36
-rwxr-xr-x 1 admin users 29437 Jul 30 16:57 Copia de Libro2.xlsx
drwxr-xr-x 1 admin users    42 Nov 21 20:28 Drive
drwxr-xr-x 1 admin users     0 Nov 21 20:25 googledrive
-rwxrwxrwx 1 admin users   401 Nov 17 14:39 rclone_mountstar.sh
drwxr-xr-x 1 admin users     0 Jan  6  2019 www

But if I try to make a copy using the DSM interface I get this error:


"This action is not compatible?" Sorry my Spanish is not very good. Let me know if that's not right.

Perhaps this is not relevant but... Why does your command indicate
rclone mount drive: /volume1/Ilimitado
but in your explanation you seem to be expecting a mount to be on /homes/admin/googledrive ?
These obviously have to match. Or are you using two different examples here? Please clarify.

I recommend you remove --allow-non-empty flag. While it has valid usecases, it can only serve to confuse the situation here. You should have no reason to use it here, and it's a "risky" flag to use unless you understand it fully.

In general I would (for now) just remove all the flags except for --allow-other and test with that. It is just much easier to troubleshoot if we test with a bog-standard setup. Once we get it working you can add back the flags later. None of them (aside from maybe --allow-other) will be essential here.

I took a look at the guide and I can't see anything "special" in these instructions. It's pretty standard - so at least it does not seem like there are any special quirks for Synology (according to the user who wrote the guide at least).

Yeah, sorry. In this case I mounted it in a new folder called googledrive for this particular case, just in case the previous folder had some kind of error.

I've tried to mount it using only the flag you tell me and it doesn't work either and yes, you have succeeded in translating into Spanish :smiley:

In the DSM log I found this:

2019-11-21T21:23:14+01:0= synoscgi_SYNO.FileStation.CopyMove_3_start[30117]: copy/copy_file_copy.c:328 failed to statfs /volume1/homes/admin/googledrive, reason=[(18)Invalid cross-device link]

2019-11-21T21:23:14+01:00 synoscgi_SYNO.FileStation.CopyMove_3_start[30117]: SYNO.FileStation.CopyMove.cpp:1504 Failed to copy /volume1/homes/admin/Copia de Libro2.xlsx to /volume1/homes/admin/googledrive/Copia de Libro2.xlsx, reason=[2000], Invalid cross-device link

Can you run this command for me and paste the result please? I have a hunch about what may be wrong here...

lsblk -no name,fstype

Here is manual for lsblk if you need it:

Synology doesn't have that command. Any alternative? I understand that it is to know the state of the disks

Ok, so in short - my hypothesis here (without knowing a lot about Synology systems and just going of what I can google) is that...

FUSE uses exFAT by default (or maybe is the only option, I am not sure as I usually work on Windows which uses Winfsp with NTFS format).

And Synology systems generally do not appear to support exFAT out of the box according to google. That would mean that DSM can't speak to the fusemount. In that case the error you see would make perfect sense.
According to google it should be possible to install exFAT support however. Alternatively FUSE might support an alternative format you can use on the mount. This I don't really know about as I don't use FUSE that much directly.

@Animosity022 Do you know anything more about FUSE's filesystem format on Linux?

Perhaps exFAT support was part of the prerequisites that the guide mentioned to install from
But since I don't know what's in that package this is just speculation on my part. It would perhaps explain why this was not mentioned in the guide explicitly, so it's worth doublechecking that part of the installation again to make sure you didn't miss some part of it.

The command I gave you was just to verify that your current mount is in fact running on exFAT. Animosity can probably just tell us that though, so it's probably not a critical test to run.

on synology, exfat is not installed by default.


Yeah, i install this package and it’s works.
Thanks you men!

Nice! Thanks for the assist and link asdffdsa :+1:

sure, providing the link was easy,
i have a few customers using the sinology box and i once tried to plug in a usbkey formatted as exfat and found out i needed to install an addon.
something to do with micro$oft licensing, of course.

but that you knew that "FUSE uses exFAT by default ", that was the main thing.
and as i think about it, that statement while true makes zero sense to me, more like negative sense.
as fuse is linux and it depends on micro$oft licensed product.

It may perhaps have been a conscious design choice in order for the system to be maximally inter-compatible. Most Linux distros have exFAT support anyway don't they? Or perhaps it was just easier to implement on a technical level somehow. I can only speculate - but there was probably a good reason for it.

i know this is off-topic but i happen to be watching star trek the next generation season 05 episodes 07+08.
in these episodes, spock makes an appearance.
as i hope you know spock is half.human/half.vulcan.
kinda, sorta, a little like a meld of windows and linux.

human=  windows
vulcan= linux

and as you know i am a half-bred - half.monkey/half.human.
so spock is my hero. that one day my half.monkey can become half.vulcan.
we all have dreams!