sync error under linux report 2118077980


I have a sync error in combination with problems to attach a pdf-file to an entry. The error report is: 2118077980

I "grabed" an entry on with zotero from my browser. Unfortunately the pdf is not automatically downloaded by the zotero import filter. So I manually download the pdf-file into a temporary archive. Then right-click on the zotero-item and attach a stored file to the item. Normally that works. In this case it did not work. In parallel I noticed, that zotero tries to sync but ends with an error report. (note: I could open and read the pdf-file, so the file exists on my linux-machine and is not broken).

I tried to rename the file (I remember I once had a similar problem that could be solved by that) to abc.pdf but that did not help. I manually created an article-item and tried to attach the pdf to that item but this neither worked.

Finally I opend zotero on my mac-desktop. Although I got an sync error on the linux machine it did sync the zotero item. I than copied the pdf-file from the linux machine to the mac and attached it to the item on my mac. It worked and the mac version of zotero synced without error message.

After that I could sync back to my linux machine but still get the error although the pdf now appears in the list inside zotero and is readable by clicking on the item.

One aditional note to my specific system configuration: I run zotero under linux (ubuntu 16.04 lts derivate elementary) but the storage for attachements is on an internal ntfs-hdd because I have a dual boot system and need to access the data partition as well under windows. But as mentioned before I use zotero regularly and did not had trouble with this configuration so far.

On Linux runs zotero 5.0.64. On Mac (10.10.5) zotero is still on 5.0.60.

Now I would like to understand what the sync error is about since it seems to sync anyway and if it might have to do with the trouble I had with the pdf-file.

Thanks for any hint
  • Unix error 1 during operation setPermissions on file /media/[…]/Zotero/storage/IB8B322D/png_003.dat (Vorgang nicht zulässig)
    Something about your filesystem setup is interfering with Zotero's ability to access the disk. I'm afraid I can't help beyond that.
  • I still have trouble. The filesystem rights to the zotero base-folder are set to 777 so anybody can write and there should be permission. Yesterday I tried to get rid of the trouble by creating a new folder and sync the whole zotero files anew. With the same result of errors. See Report nr 2086022575
    I think it might be a problem with zotero having problems to handle my dual-boot system. I have two HDD: one SSD where two Linux and one WIN 10 distributions reside. One conventional HDD where my data goes. I use Zotero on this computer only under one of the Linux distributions. But there are other data I use with different distributions. Therefor the Data-HDD is formated with NTFS filesystem. Maybe Zotero expects a different filesystem when running under Linux and therefor has trouble?
    I do not know if this has to do with it, but Zotero runs now also into trouble at work under Windows. See report nr 1553991583

    My old Zotero folder under Linux counts:
    6.2 GB with 4302 folders and 91,684 files

    My new synced Zotero folder under Linux counts:
    4.9 GB with 4276 folders and 6464 files

    on my workplace the Zotero folder counts under Win10:
    6.15 GB (6.28 on disk) with 4,274 folders and 96,308 files

    It seems with resyncing zotero I have lost more than 80,000 files. Feels alarming (although I have the old folder as backup).

    Any idea how I can proceed to get syncing work again?
  • Zotero doesn't know or care about the filesystem type, but it does expect to be able to set POSIX permissions on Linux, so if the NTFS filesystem driver doesn't properly emulate those, I imagine you could easily get the above error. You should try storing your Zotero data on a proper Linux filesystem. That's really all we can suggest.
    Win error 145 during operation removeEmptyDir on file C:\Users\[…]\Zotero\storage\T5PN23QB
    We can look at the problem on your work computer once you've solved the problem on your own computer, but that's likely caused by security software or some other odd filesystem intervention that the computer is doing.
  • Ok, that makes some sense. I originally used a commercial ntfs driver but after a kernel upgrade on the ubuntu based system it stopped working and I had to switch back to the open source drivers.
    On the WIN machine I had after the system upgrade trouble with security warnings when opening word documents. In response the IT did deactivate some security software that interfered. I thought they did so globally on my computer but maybe still something interferes.
  • edited February 13, 2020
    I could partially fix the linux problem. It indeed seems that zotero works well with the paragon ntfs for linux driver but get into trouble with the open source ntfs3g drivers that are default on most linux systems. I installed zotero on my test-linux where I have installed the paragon drivers and it synced zotero without error. Unfortunatly my attemps to install the paragon drivers on my working linux installation failed - but that for shure is not a zotero problem.

    The problem on the Windows installation at work still persists. See error report 1047715912. I discuss this problem here, although it seems to me a different case, because you closed the discussion I opend to that problem with the remark it should be discussed in this discussion.

    Getting more deeply into it it seems the errors occur only with saved screenshots. In various cases zotero can not find the html file to start with although it is there. When reconnecting that existing file with the zotero database ("locate file" dialog) it shows up well in Zotero.
    But still I got remaining errors that state, the directory could not be removed because it is not empty. Fair enough - it is not empty and should not be removed. It seems that this occurs on a series of saved wikipedia entries where the name of the entry and file includs some special charectes of accent like é.
    On the linux side I could find the same entries and there the filenames are displayed well within zotero but on the filesystem show strange characters. I changed the filenames with Zotfile extension and resynced. But still syncing the windows side shows the errors mentioned in the report named above.
    And strange enough: On the windows side the directories at stake are nearly empty only containing a file with a very long cryptic name that includes only a brief 403-error message in html code. This while on the Linux machine the same entry holds a complete screenshot of a webpage.

    So my question goes how i can reset these 10 or so entries without having to sync almost 6 GB of data totally anew. I refrain from just deleting manually (on OS-level) the respective data in storage. A consistency test for the database from within Zotero showed no errors and no effect.
  • I tried some more and it is getting more and more strange. I thought as a work around I might duplicate the errant entries by copy them to a group library. Sync theme and then copy back to the original library.
    The first step worked fine and after syncing I can open the screenshot well from the group library. But while trying to copy the synced entry back to the original library it does not work. It shows no error but it do not copy anything. I tried also to rename the copy and the original but nothing worked out to copy the working version of the entry back to my own library.
  • The copying thing is just how cross-library drags currently work. You'd have to delete the original item and empty the trash before copying back.

    But it would be better to troubleshoot the original issue, since you're likely to just run into this again.
    It seems that this occurs on a series of saved wikipedia entries where the name of the entry and file includs some special charectes of accent like é.
    In your latest error report there are still files with malformed characters. This may actually be related to the Linux filesystem driver as well — Unicode characters should sync fine across platforms, but if they're getting stored in some unusual way on Linux they might caused problems elsewhere.

    Can you provide a Debug ID for (different from a Report ID) for a sync that triggers this error?
Sign In or Register to comment.