Introduction
The Media Transfer Protocol (MTP) provides us direct file access to devices such as our smart phones and other devices that choose to use the protocol. In my case, my Nexus 4 couldn’t correctly attach itself to my system. From my Google results; it seemed to be due to the version of libmtp I was running. You see, CentOS/RHEL ships with libmtp v1.0 and most of the support for cell phones that came out within the last 2 years isn’t available until v1.1. libmtp v1.1 additionally builds against most peoples FUSE implementations such as MTPfs, jmtpfs and simple-mtpfs. It’s through these FUSE/MTP implementations that we can easily mount and directly access the content on our smart phones and tablets that use the MTP protocol.
So upgrade libmtp already; why are you blogging about it?
Oh boy… well here are all the problems I faced:
- VLC Media Player is built against this same library. Upgrading it means looking after this dependency too; or go without it (no, not going to happen).
- Rhythmbox is also built against this same library (libmtp). Upgrading it means looking after this dependency too; or go without it (again… not going to happen).
Then the second problem… we’ve only tackled the upgrade of libmtp above if we go through with this… we still haven’t even tackled the FUSE implementation. Here are the results I had testing some of them:
- MTPfs: At the time of this blog, the last update for this software was on February 4th, 2010. I got the software to compile by simply using the version that ships with Fedora 18 (1.1-0.3.svn20120510) but when I tried to use it, it just hung as a normal user. If I tried mounting the device as root it would fail (see below):
$ mkdir media $ # As myself (non-root) $ mtpfs media/ Listing raw device(s) Device 0 (VID=18d1 and PID=4ee1) is a Google Inc (for LG Electronics/Samsung) Nexus 4/10 (MTP). Found 1 device(s): Google Inc (for LG Electronics/Samsung): Nexus 4/10 (MTP) (18d1:4ee1) @ bus 2, dev 89 Attempting to connect device libusb_open() failed!: Permission denied LIBMTP PANIC: Unable to initialize device Unable to open raw device 0 $ # As root (superuser) $ sudo mtpfs media Listing raw device(s) Device 0 (VID=18d1 and PID=4ee2) is a Google Inc (for LG Electronics/Samsung) Nexus 4/10 (MTP+ADB). Found 1 device(s): Google Inc (for LG Electronics/Samsung): Nexus 4/10 (MTP+ADB) (18d1:4ee2) @ bus 2, dev 73 Attempting to connect device Android device detected, assigning default bug flags Error 1: Get Storage information failed. Error 2: PTP Layer error 02fe: get_handles_recursively(): could not get object handles. Error 2: Error 02fe: PTP: Protocol error, data expected Listing File Information on Device with name: (NULL) LIBMTP_Get_Storage() failed:-1
Now I don’t want to give MTPfs a bad name. It’s quite possible that it works really well but just not for my personal purposes. In fact it compiles perfectly in CentOS/RHEL 6 right out of the box without any modifications. Therefore just because it didn’t work for me doesn’t mean it won’t necessarily work for you. For this reason and the fact it was once maintained (up to Fedora 18) I’ll include my results with it here too.
- jmtpfs worked the best for me. The only problems I ran into with this software was that it wasn’t already packaged for CentOS/RHEL. The only thing I had to work with for packaging it myself was a very long set of comments (see the link back to it’s official site to see what I’m talking about). That all said; the software works fantastic right out of the box. Kudos to the great work of the developer and his online support.
- simple-mtpfs works well too but required some tweaking to make it possible. You see, simple-mtpfs relies on the new C++11 compiling features and standards (which truly are amazing BTW) but weren’t available during the release of CentOS/RHEL 6. Making these standards available by upgrading the glib core library to a newer version would be just crazy. In fact, you could seriously risk jeopardizing the stability of the OS itself since everything else would have been compiled against the old version. So, to work around this, I wrote a small patch file for portions of the simple-mtpfs code mimicking the old behavior prior to the C++11 standards.
Just hand over everything
Of course… and as always; I planned on it. Hopefully you’ll find the packages useful! Like my other blogs, the installation instructions will be near the bottom of this blog, along with the ‘do it yourself’ for those who don’t trust the sources.
First thing is first; this is what makes everything else tick:
- libmtp-1.1.6-2.el6.x86_64.rpm
- libmtp-examples-1.1.6-2.el6.x86_64.rpm (Optional)
- libmtp-devel-1.1.6-2.el6.x86_64.rpm (Optional)
Here are the dependencies you may or may not need to get out of the way. Note that I just went ahead and upgraded VLC to 2.0.6 (from the stock version 1.1). There may be other dependencies of libmtp you find that I didn’t simply because I didn’t use those packages. You can just assume that all of the binary packages listed below have been compiled against libmtp v1.1 (shared above).
- rhythmbox-0.12.8-1.el6.x86_64.rpm
- rhythmbox-upnp-0.12.8-1.el6.x86_64.rpm
- vlc-2.0.6-1.el6.x86_64.rpm
- vlc-core-2.0.6-1.el6.x86_64.rpm
- vlc-extras-2.0.6-1.el6.x86_64.rpm
- vlc-plugin-jack-2.0.6-1.el6.x86_64.rpm
- vlc-devel-2.0.6-1.el6.x86_64.rpm
After you’ve got libmtp correctly installed and your system appears to be right back in the state it was previously, we can now move on to adding one of the excellent FUSE/MTP packages some incredible developers have put together for us.
- jmtpfs-0.4-1.el6.x86_64.rpm
Author: Jason Ferrara (Website)
Source: jmtpfs-0.4-1.el6.src.rpm
Compilation Details: I made 1 small patch file (see here) introducing some of the nice idea’s his followers of his blog suggested for auto-mounting. I additionally had to make one small change so that his code could compile against the version of FUSE currently shipped with CentOS/RHEL 6. The only other thing I can take credit for is the rpm packaging itself; the rest of the work was that of the hard working developer who made this application possible. The spec file I wrote can be seen here. - simple-mtpfs-0.1-8.el6.x86_64.rpm
Author: Peter Hatina (Website)
Source: simple-mtpfs-0.1-8.el6.src.rpm
Compilation Details: I created 2 separate patch files for this to properly compile in CentOS/RHEL. The first patch rolls back the C++11 coding styles to the older way of doing it (so it can compile against our existing libraries). The second patch introduces the auto-mounting for our environment (exactly how It was done in my patch for jmtpfs). To accommodate these patch files I needed to additionally update the spec file which you can view here. - mtpfs-1.1-0.3.svn20120510.el6.x86_64.rpm
Author: Chris Debenham (Website)
Source: mtpfs-1.1-0.3.svn20120510.el6.src.rpm
Compilation Details: No magic went on here; I just grabbed the packaged code from a Fedora 18 release on pkgs.org and it compiled without any problems. Note: It appears the support for this package was dropped after Fedora 18 since it isn’t available for either Fedora 19 or 20.
Here are the source packages for those who are interested:
Show me what you did; I’m not using your stuff
In some cases you’ll need to use what I’ve done (patch wise); but to be as transparent as possible, I’ll show you how you can easily build everything and review all of what is going on before committing to using it. Now keep in mind also; there is A LOT of stuff covered here. There is libmtp itself, the dependencies issues and then finally the choice of FUSE/MTP implementation. I’ll cover the dependencies last since not everyone will have this issue.
First I set up a mock environment to work in; this allows us to do compiling outside of our native environment and means we don’t need to ever install any development libraries.
First prepare our development environment with mock if you haven’t already:
# Install 'mock' into your environment if you don't have it already # This step will require you to be the superuser (root) in your native # environment. yum install -y mock # Grant your normal every day user account access to the mock group # This step will also require you to be the root user. usermod -a -G mock YourNonRootUsername
At this point we can get away from the root user and build using our own user we created for our system.
Now we’ll cover libmtp v1.1 as everything revolves around this library.
# Fetch the latest copy (already packaged) of libmtp wget http://dl.fedoraproject.org/pub/fedora/linux/development/20/source/SRPMS/l/libmtp-1.1.6-2.fc20.src.rpm # As time goes on, this rpm may not be available, but # you should be able to just get away with grabbing the latest # copy of libmtp from http://pkgs.org # Now we just rebuild it against our own environment mock -v -r epel-6-x86_64 --resultdir=$(pwd)/results --rebuild libmtp-1.1.6-2.fc20.src.rpm # Now all our built RPMs will be in a directory # entitled 'results' to make things easier, we'll just # move it all into the directory we're working in now find results -name '*.rpm' -exec mv {} . ; # We can eliminate the results directory now rm -rf results
Everything from this point forward assumes we have a built copy of libmtp to work with. Now we’ll focus on the FUSE/MTP options.
- Option 1: simple-mtpfs
# Fetch our source wget --output-document=simple-mtpfs-0.1-8.el6.src.rpm https://www.dropbox.com/sh/9dt7klam6ex1kpp/KEU68ZzLIv/20131015/mtp/simple-mtpfs-0.1-8.el6.src.rpm?dl=1 # Initialize our Environment mock -v -r epel-6-x86_64 --init # Now install the nessisary dependencies for simple-mtpfs # which we must additionally include the libmtp package we # just built mock -v -r epel-6-x86_64 --install libmtp-1.1.6-2.el6.x86_64.rpm libmtp-devel-1.1.6-2.el6.x86_64.rpm fuse-devel # Now if you don't have any insecurities with source rpms you # can finish with the next command... or you can skip it and # extract all of it's content for inspection before building. # all of the results will appear in the 'results' directory. # Note: You'll want to skip this step and move to the next if # you have any insecurities at all. mock -v -r epel-6-x86_64 --no-clean --resultdir=$(pwd)/results --rebuild simple-mtpfs-0.1-8.el6.src.rpm # For those really insecure can keep reading and perform # the following steps instead of the single command above # Copy our source into the mock building environment mock -v -r epel-6-x86_64 --copyin simple-mtpfs-0.1-8.el6.src.rpm /builddir/build # Shell into our environment now mock -v -r epel-6-x86_64 --shell # Change to the build directory cd builddir/build # Install the source package (which will deploy within # the mock environment only) rpm -Uhi simple-mtpfs-0.1-8.el6.src.rpm # Now we can safely prepare the source for inspection. # - the spec file will be in the SPECS/* directory # - all patch files and source code will be in SOURCES/* # # Once your satisfied I'm not out to get you, you can build # the package: rpmbuild -ba SPECS/simple-mtpfs.spec # we're now done with our mock environment for now; Press Ctrl-D to # exit or simply type exit on the command line of our virtual # environment exit # We'll return to the directory we were previously in. We can copy # out the packages we just built at this point. Ignore the warning # about SELinux if you get one because it doesn't impact our goals. mock -v -r epel-6-x86_64 --copyout /builddir/build/SRPMS/simple-mtpfs-0.1-8.el6.src.rpm . mock -v -r epel-6-x86_64 --copyout /builddir/build/RPMS/simple-mtpfs-0.1-8.el6.x86_64.rpm . mock -v -r epel-6-x86_64 --copyout /builddir/build/RPMS/simple-mtpfs-debuginfo-0.1-8.el6.x86_64.rpm .
- Option 2: jmtpfs
# Fetch our source wget --output-document=jmtpfs-0.4-1.el6.src.rpm https://www.dropbox.com/sh/9dt7klam6ex1kpp/KH6b9pmCRZ/20131015/mtp/jmtpfs-0.4-1.el6.src.rpm?dl=1 # Initialize our Environment mock -v -r epel-6-x86_64 --init # Now install the necessary dependencies for jmtpfs # which we must additionally include the libmtp package we # just built mock -v -r epel-6-x86_64 --install libmtp-1.1.6-2.el6.x86_64.rpm libmtp-devel-1.1.6-2.el6.x86_64.rpm fuse-devel file-devel # Now if you don't have any insecurities with source rpms you # can finish with the next command... or you can skip it and # extract all of it's content for inspection before building. # all of the results will appear in the 'results' directory. # Note: You'll want to skip this step and move to the next if # you have any insecurities at all. mock -v -r epel-6-x86_64 --no-clean --resultdir=$(pwd)/results --rebuild jmtpfs-0.4-1.el6.src.rpm # For those really insecure can keep reading and perform # the following steps instead of the single command above # Copy our source into the mock building environment mock -v -r epel-6-x86_64 --copyin jmtpfs-0.4-1.el6.src.rpm /builddir/build # Shell into our environment now mock -v -r epel-6-x86_64 --shell # Change to the build directory cd builddir/build # Install the source package (which will deploy within # the mock environment only) rpm -Uhi jmtpfs-0.4-1.el6.src.rpm # Now we can safely prepare the source for inspection. # - the spec file will be in the SPECS/* directory # - all patch files and source code will be in SOURCES/* # # Once your satisfied I'm not out to get you, you can build # the package: rpmbuild -ba SPECS/jmtpfs.spec # we're now done with our mock environment for now; Press Ctrl-D to # exit or simply type exit on the command line of our virtual # environment exit # We'll return to the directory we were previously in. We can copy # out the packages we just built at this point. Ignore the warning # about SELinux if you get one because it doesn't impact our goals. mock -v -r epel-6-x86_64 --copyout /builddir/build/SRPMS/jmtpfs-0.4-1.el6.src.rpm . mock -v -r epel-6-x86_64 --copyout /builddir/build/RPMS/jmtpfs-0.4-1.el6.x86_64.rpm . mock -v -r epel-6-x86_64 --copyout /builddir/build/RPMS/jmtpfs-debuginfo-0.4-1.el6.x86_64.rpm .
- Option 3: mtpfs
# Fetch our source from pkgs.org wget http://dl.fedoraproject.org/pub/fedora/linux/releases/18/Everything/source/SRPMS/m/mtpfs-1.1-0.3.svn20120510.fc18.src.rpm # Initialize our Environment mock -v -r epel-6-x86_64 --init # Now install the necessary dependencies for mtpfs # which we must additionally include the libmtp package we # just built mock -v -r epel-6-x86_64 --install libmtp-1.1.6-2.el6.x86_64.rpm libmtp-devel-1.1.6-2.el6.x86_64.rpm autoconf automake libid3tag-devel glib2-devel fuse-devel # If you have insecurities at this point, you'll need to # take them up with someone else since I didn't make any # modifications to this FUSE/MTP option at all. So we # just need to build from source at this point. mock -v -r epel-6-x86_64 --no-clean --resultdir=$(pwd)/result --rebuild mtpfs-1.1-0.3.svn20120510.fc18.src.rpm
Finally our libmtp dependency issues (if you have them).
- Rhythmbox
# Fetch our source from pkgs.org wget http://vault.centos.org/6.4/os/Source/SPackages/rhythmbox-0.12.8-1.el6.src.rpm # Initialize our Environment mock -v -r epel-6-x86_64 --init # Now install the necessary dependencies for Rhythmbox # which we must additionally include the libmtp package we # just built mock -v -r epel-6-x86_64 --install libmtp-1.1.6-2.el6.x86_64.rpm libmtp-devel-1.1.6-2.el6.x86_64.rpm # Now we just rebuild from source using the new library mock -v -r epel-6-x86_64 --no-clean --resultdir=$(pwd)/results --rebuild rhythmbox-0.12.8-1.el6.src.rpm # Your rpm's will appear in the 'results' directory.
- VLC
# The catch with VLC is it's development isn't frozen with # the version of CentOS/RHEL like Rhythmbox does. This is because # if your running this, you've already chosen to link to other # repositories like RPMForge, ATrpms, LinuxTECH, etc. # Mock however (out of the box) does not link to these locations # at all. The quickest (and dirty) work around to this fix is to # simply install 'yum' into the mock environment which we can # use to fetch all of our dependencies (the best way is to actually) # create a new mock configuration that just includes them. But # everyone uses to many different alternatives; so we'll do it # my way :) # Fetch VLC source from the repository you use. You can do this # using yum if you have the --download-only rpm addon. Otherwise # just utilize pkgs.org and get the package: # http://pkgs.org/search/?keyword=vlc&search_on=name&distro=82&exact=1 # At the time v2.0.6-1 was the version available to me. # You may need to adjust the below commands depending on which # package you get; I'll use a variable so you can set it to # whatever you get at the time. # If you are comfortable just using the version I have; you can # download it here: wget --output-document=vlc-2.0.6-1.el6.src.rpm https://www.dropbox.com/sh/9dt7klam6ex1kpp/pm7MCGHa9K/20131015/mtp/vlc-2.0.6-1.el6.src.rpm?dl=1 # Set this variable to something else if you fetched a different # version VLCVER=2.0.6-1 # Store our original source RPM Name; we do it this way # because some people might use different packages that # have the ending f20 (Fedora), atr (ATrpms), rf (RPMForge), etc # This way we're working with the same file regardless of # the version you picked VLCSRPM=$(find -name "vlc-$VLCVER.*.src.rpm" 2>/dev/null) # Make sure we found your rpm at this point # The following should output a file that exists echo $VLCSRPM # Initialize our Environment mock -v -r epel-6-x86_64 --init # Now install the nessisary dependencies for vlc which we must # additionally include the libmtp package we just built # including 'yum' so we'll fill all the dependencies mock -v -r epel-6-x86_64 --install libmtp-1.1.6-2.el6.x86_64.rpm libmtp-devel-1.1.6-2.el6.x86_64.rpm yum # Now this is the dirty trick I was telling you about; we'll # just install your current yum repositories into your mock # environment. This will make it really easy to fill our # dependency problems: find /etc/yum.repos.d/ -maxdepth 1 -mindepth 1 -type f -name '*.repo' -exec mock -v -r epel-6-x86_64 --copyin {} /etc/yum.repos.d/ ; # Now we want to copy our VLC Source into the environment mock -v -r epel-6-x86_64 --copyin $VLCSRPM /builddir/build # Shell into our mock environment mock -v -r epel-6-x86_64 --shell # Change to our building directory cd /builddir/build # Install all our dependencies including our source yum install $(rpm -qp --requires vlc*.src.rpm | cut -d' ' -f1) # Install our source RPM rpm -Uhi vlc*.src.rpm # There is a chance this failed for you... if so # you can use the collection of rpms I built manually # to make it possible for me; just visit here: # https://www.dropbox.com/sh/9dt7klam6ex1kpp/_pczPoH-Wx/20131015/mtp/dep.vlc2.0 # You can exit the shell (Ctrl-D) or type exit and by now # you should have enough info as to how you can install these # rpms into your mock environment using mock and --install # Now build your RPM (this can take some time): rpmbuild -ba SPECS/*.spec # We're now done with our mock environment for now; Press # Ctrl-D to exit or simply type exit on the command line # of our virtual environment exit Now just copy out our packages: mock -v -r epel-6-x86_64 --copyout /builddir/build/SRPMS/vlc-$VLCVER.el6.src.rpm . mock -v -r epel-6-x86_64 --copyout /builddir/build/RPMS/vlc-$VLCVER.el6.x86_64.rpm . mock -v -r epel-6-x86_64 --copyout /builddir/build/RPMS/vlc-core-$VLCVER.el6.x86_64.rpm . mock -v -r epel-6-x86_64 --copyout /builddir/build/RPMS/vlc-extras-$VLCVER.el6.x86_64.rpm . mock -v -r epel-6-x86_64 --copyout /builddir/build/RPMS/vlc-plugin-jack-$VLCVER.el6.x86_64.rpm mock -v -r epel-6-x86_64 --copyout /builddir/build/RPMS/vlc-devel-$VLCVER.el6.x86_64.rpm mock -v -r epel-6-x86_64 --copyout /builddir/build/RPMS/vlc-debuginfo-$VLCVER.el6.x86_64.rpm # You're done now! Phewf...
Installation
The installation will vary depending on your environment. If you are using either VLC or Rhythmbox, your life might be easier if you uninstall them now (knowing your going to re-install them again shortly).
yum remove rhythmbox vlc
Now you can install libmtp and your choice of FUSE/MTP implimentation (as root):
- Option 1: simple-mtpfs
yum localinstall libmtp-1.1.6-2.el6.x86_64.rpm simple-mtpfs-0.1-8.el6.x86_64.rpm
- Option 2: jmtpfs
yum localinstall libmtp-1.1.6-2.el6.x86_64.rpm jmtpfs-0.4-1.el6.x86_64.rpm
- Option 3: mtpfs
yum localinstall libmtp-1.1.6-2.el6.x86_64.rpm mtpfs-1.1-0.3.svn20120510.el6.x86_64.rpm
It’s important to note that you can go ahead and install all 3 options if you really wanted to (but it’s not really worth it). Pick one… if it doesn’t work well for you, try another.
Feel free to reinstall any other packaging you were using:
# VLC v2.0 yum localinstall vlc-core-2.0.6-1.el6.x86_64.rpm vlc-2.0.6-1.el6.x86_64.rpm # Rythmbox v0.12.8 yum localinstall rhythmbox-upnp-0.12.8-1.el6.x86_64.rpm
It still isn’t mounting for me:
Some phones/tablets may require you to toggle the USB debugging mode of your phone and/or tablet for things to work smoothly for you. If you already have it enabled, then try disabling it. This is what I had to do with my Nexus 4 anyway; it worked beautifully for me after I toggled this option. I think this may be a bug with the current MTP v1.1 libraries that don’t seem to correctly handle the mounting of the device when being first connected. But whatever handshaking goes on, through the toggling of this option corrects the problem. I’m sure we will see this resolved in future builds.
Other MTP Alternatives
There are other alternatives; but this blog was going to be long enough just trying to share the ones I chose already.
- FUSE Binding for Go is another alternative I didn’t test which seems to have a lot of active development on it as well. For those who aren’t familiar with The Go Programming Language, it is basically a fairly new language that is catching on with a lot of developers.
- Gnome MTP is designed to be a simple MP3 player client for MTP based devices.
Credit
Please note that this information took me several days to put together and test thoroughly. I may not blog often; but I want to re-assure the stability and testing I put into everything I intend share.
If you like what you see and wish to copy and paste this HOWTO, please reference back to this blog post at the very least. Itβs really all I ask.
Sources:
- I used pkgs.org to obtain rpm source packaging for vlc (v2.0.6), rhythmbox (v0.12.8), libmtp (v1.0), mtpfs (v1.1), and simple-mtpfs (v0.1) so I could rebuild with content that was already stable and tested.
- Not the official website, but this website gives a good breakdown of the different MTP applications as well as the out of the box libmtp commands you can use. Wikipedia has some good info on it as well.
- libmtp official website.
- simple-mtpfs official website.
- MTPfs official website.
- jmtpfs official website.
Thank you so much! It work perfectly!
Thanks for sharing this. Finally I can access the files on my Nexus from CentOS. Also, “mock” looks extremely useful.
Thank you very much for your effort! Worked perfectly on 6.5 with jmtpfs and my Nexus 4.
Thank you! It worked for my MOTO G
Thank you. It work for me (on centos 6) with the mtpfs command.
The error :
Error 2: Error 02fe: PTP: Protocol error, data expected
Listing File Information on Device with name: (NULL)
occured (as root) when the phone is locked. I’ve tried to unlock the phone before execute the mtpfs command and that works.
Adri,
I had the exact same problem with mtpfs as you did (it has nothing to do with your phone being locked or not). The error is also documented above in my blog in case you had missed it. In this case, I suggest you try one of the other 2 other options I wrote about instead. My personal advice for you is to uninstall mtpfs and install jmtpfs instead. Try fetching the package from my repository instead of my blog. That way you’ll get the updated version of it (v0.5) instead. But jmtpfs v0.4 works great too if you choose to use the working copy linked from this blog instead.
Thank you for this. Amazing work!
indeed very kind of you to share this
Thanks a lot for such amount of work “pro bono”. I have installed jmtpfs and it works fine on my CentOS 6.6 machine with one exception. Unmounting my phone (Motorola Moto-X) or tablet (ASUS Transformer Pad TF300TG) requires root priviledges. Otherwise I get “umount: /media/mtp1-3 is not in the fstab (and you are not root)”. Any idea why it is so?
Michal,
MTP isn’t like EXT3, XFS, VFAT, NTFS, etc… You don’t ever need to unmount it. MTP was designed to prevent disk corruption during data transfers (and people not correctly detaching their devices). With MTP, the device looks after it’s own filesystem instead of leaving it for the operating system that mounted to it. In short, it’s 100% safe to just pull the device out when you’re done with it! You do not need to unmount it first. π
If it really bothers you and you still want to eliminate it prior to unplugging it, see the script: /usr/sbin/umountjmtpfs as it does all of the work. It is called automatically when you unplug you device. You’ll see that it doesn’t utilize the umount command since that isn’t a FUSE command. I hope this info helps!
Hi,
Awesome work, thank you so much! We have CentOS 6.6 workstations at work, and some people use Android tablets to do stuff on the go. Now we can finally interface them properly, thanks to you (also used jmtpfs, works nicely enough even for unknown devices)!
By the way: We do not need it, but your “vlc-plugin-jack-2.0.6-1.el6.x86_64.rpm” link is wrong, as it points to “https://www.dropbox.com/sh/9dt7klam6ex1kpp/BD4jP3uJU2/20131015/mtp/vlc-extras-2.0.6-1.el6.x86_64.rpm?dl=1”. You may wish to fix that. π
Best,
Michael
I’ve now fixed that link; thank you for pointing it out! I’m glad all is working for you and your team.
That was fast! π
I’m trying to do a USB link between my desktop (CentOS-6) and my Nexus-9 (android 6). I have followed the instrictions here and I see the “Internal storage” directory in Nautilus. I can go down two directory levels from that and then it won’t show any more — no further directories, no files, etc. I know there are some, because I can see them using Total_Commander on the Nexus. Can you suggest a solution? Thanks
Joe Henley
The protocol just basically passes the list of files back and forth. So things that could interrupt this would be a very long USB cable (you might be picking up noise or interference). Try using another cable to connect your phone with (preferably a shorter one). The only other thing I can think of would be if the directory you’re listing the contents of is huge (thousands of files?). Do other directories 2 levels down list their contents okay? Maybe it’s getting stuck reading a file with a strange encoding or character in its filename?
Hi Chris,
Thanks for the reply!
The issue remains with two different USB cables (different lengths), in all the (10 to 15) directories I tested, and across directories with zero thru 25+ files. I didn’t find any files with “strange characters” in the file name for testing. And it occurs only at the second directory level; no problem at the first level, and I can’t test any at the third level …. as I can’t get past the second.
So, I removed mtpfs and installed jmtpfs. Now it works fine. So the issue is clearly with mtpfs.
Joe Henley
That’s great! π I’m glad you figured it out! I have a newer version of jmtpfs too here if you want it.