[genomeHunter]

Try to run the "configuration-assistant.perl" that is present in the "bin" directory.

While you are running the perl script you will reach a point where the software asks you "Would you like to test SRA files for remote reference dependencies? [y/N]". Choose "Yes" (default answer is No) which will then prompt you to provide an SRA accession number. Try providing the SRA# you are having problems with and see if the script downloads the right reference files.

Try "fastq-dump"ing that SRA file.

There is also a possibility that some SRA files may be corrupt or otherwise problematic (happened with one I was interested in). You may want to ask SRA support to check on the problematic accession #'s.

I have tried everything, in every forum, and in every thread.

I simply cannot understand why such a presumably simple and tiny application could cause so much headache. It just cannot be solved

Last thing I tried, without success:

http://trace.ncbi.nlm.nih.gov/Traces...lkit_doc&f=std

GH

[genomeHunter]

Solution

I think I have finally found the solution!

Some new SRA files need refseq for dumping. It should be in ~/ncbi/public/refseq (default path). For some reason, my SRA toolkit was unable to download them, so I manually downloaded them from

ftp://ftp-trace.ncbi.nlm.nih.gov/sra/refseq/

Try running 'vdb-validate' and 'test-sra +a' to see which sequences you need to download.

Cheers
GH

PS. SRA technical staff are friendly and knowledgable. Contact them if the problem persists! :-)

[giorgifm]

Guys,

the problem happens when you use a local path for the SRA file. Try using the absolute path! fastq-dump /data/etc/SRR00000.sra should do the trick

[tman]

I had this issue as well and providing the absolute path was not resolving it. In the end I found that the error (virtual file system) had to do with the machine not having web access. Copying the required reference files into: /yourhomedir/ncbi/public/refseq solved it.

[Nick]

I think I have finally found the solution!

Some new SRA files need refseq for dumping. It should be in ~/ncbi/public/refseq (default path). For some reason, my SRA toolkit was unable to download them, so I manually downloaded them from

ftp://ftp-trace.ncbi.nlm.nih.gov/sra/refseq/

Try running 'vdb-validate' and 'test-sra +a' to see which sequences you need to download.

Cheers
GH

PS. SRA technical staff are friendly and knowledgable. Contact them if the problem persists! :-)

This finally worked for me. The home mounted via NFS was not an issue. I also discovered that trying to change the default ncbi directory caused a lot issues, as a ~/ncbi directory was created after adding an encrypted repository. That is also where the refseq files have to go, even if the root is elsewhere. Basically leave the ncbi root in your home directory, and add the refseq files there.

[kmkocot]

I was having the same issue. Specifying the full path worked for me too. Thanks!

Kevin

[Richard Finney]

This is an ongoing case study in why you should just stick with sftp and gzip.

A camel is a horse designed by a committee and this SRA compression and decryption is a real camel.

[Rhewter]

Solve the problem

Hi there, I am trying to use fastq-dump on an sra file downloaded from NCBI GEO and keep getting the error message:

err: name not found while resolving tree within virtual file system module - failed to open 'SRRfilenamehere'
Written 0 spots total

I downloaded the correct version and have used this toolkit successfully on other computers. Could it be an installation issue? Thank you!

Try "fastq-dump --split-files ./library.sra".


It is works.

[sciseim]

vdb-config --restore-defaults works (I used v2.5.2)