Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

why my ext4 formatted USB drives were not mounted and playable in my M3?

This site may earn commission on affiliate links.
After reading here that the ext4 file system was now fully supported and had some nice benefits (faster indexing, less corruptible, etc..) for both music and the dashcam, I created a Ubuntu Linux VM running on the latest version of vmWare Workstation so that I can work with ext4. I easily formatted 2 different thumb drives, trying both MBR and GUID partition tables, put some MP3 music on them and my Tesla Model 3 did not recognize either drive (no USB icon appeared). I verified that both drives were fine back in Ubuntu, by playing some the music.

Does anyone have any idea why my ext4 formatted USB drives were not mounted and playable in my M3?
 
I ran into the same issue with ext4 formatted partitions created in Ubuntu. Music wasn't recognized by my Model 3 but oddly, the TeslaCam partition works fine when formatted ext4. As soon as I formatted the music partition using FAT32, it was recognized.

Apparently ext4 formatted partitions created on Macs and Windows machines with third party utilities work fine for music but those created on Ubuntu do not.
 
Check your permissions on the filesystem and on the files. I don't recall the details, but I do recall seeing a post in which it was claimed that the permissions had to be set quite permissively to enable TeslaCam to operate. The same may be true for reading music files. I'd try this:
  1. Mount the USB drive partition you want somewhere, say /mnt.
  2. As root or via sudo:
    1. chmod 0777 /mnt
    2. chmod -R a+rw /mnt/*
Note the above is from my head. I haven't tested it, so it may contain errors. The idea is to change the permissions of the filesystem itself (at /mnt) so that anybody can read from and write to it; and add read and write permissions for all users to all files and directories on the filesystem. (For the music player, write permissions should not be needed, but read permissions are.)
 
  • Like
Reactions: bijan
Ext4 support was added in one of the updates. Many are using it for music and TeslaCam.

Can you link to where you saw some official notes that ext4 not works.? Havent seen that so would like to see where that is posted / mentioned.

Note: I have seen posts here by some people saying it works for XX function and not for YY function, and thats not what I am looking for. Since you mention it was added in an update that must be mentioned somewhere.
 
Ironically, the Sentry cam works fine on the Ext4 partition on the same Thumb drive (that didn't work until very recently I've read), but the USB icon never shows up in the Media Player for my Music Ext4 partition, even after using your chmod -R a+rw /mnt/* command.
 
Can you link to where you saw some official notes that ext4 now works? Havent seen that so would like to see where that is posted / mentioned.
I don't think tesla has ever stated "officially" that it works. However, I've been using it for my music drive since late winter-spring of this year. It works well. I will, for you, state Officially® that It Works. If you choose not to believe me, do so at your peril. ;)

To the Op - I could show you the permissions as my mac reads the drive (using path finder) - I'm using the paragon extFS for mac software, which doesn't have any options for how the permissions are set, but I'm guessing they're really wide open.
Screen Shot 2019-11-10 at 11.58.41 PM.jpg
 
I just tried it twice and had no problems. My first attempt used a 16GB Kingston drive and Ubuntu 18.04; my second attempt used an 8GB Lexar drive and Ubuntu 19.10. (I thought there was a chance that the default ext4fs options might have changed between Ubuntu versions in a way that the Tesla might not like, but that doesn't seem to be the case, at least on my smallish partitions. That might still be a factor if your music partition is bigger, though.) My procedure, both times:
  1. I plugged the USB drive in and ensured that no partition from the USB drive was mounted.
  2. I partitioned the USB drive to have a single partition, using the MBR partition table, and set the partition's type code to 0x83.
  3. I created an ext4 filesystem on the drive with "sudo mkfs -t ext4 /dev/sdi1" (or "/dev/sdc1"; I used two different computers, so the USB drives showed up with different identifiers).
  4. I mounted the partition to /mnt.
  5. I typed "sudo chmod 0777 /mnt" to ensure that all users have full read/write access to the drive.
  6. I copied two directories with music, in MP3 format, to the drive.
  7. I unmounted the drive.
  8. I took the drive to my car and plugged it in.
  9. I used the Tesla's music app to look for music on the USB device. This worked both times.
  10. I successfully played music from the drive.
I suggest you try the above procedure as exactly as possible, using an 8-16GB USB drive, Ubuntu 18.04 or 19.10, and a small number of music files. To begin, use one MBR partition; don't try to start with a device that's partitioned for both Sentry Mode and music use. If you can get this to work, then begin deviating in the direction of whatever did not work -- multiple partitions, a larger USB drive, GPT, more music files, or whatever. Change one variable at a time. In that way, you'll either end up with a working configuration or you'll have discovered what's causing the problem.

FWIW, my car just upgraded to 2019.36.2.1 last night.
 
I just tried it twice and had no problems. My first attempt used a 16GB Kingston drive and Ubuntu 18.04; my second attempt used an 8GB Lexar drive and Ubuntu 19.10. (I thought there was a chance that the default ext4fs options might have changed between Ubuntu versions in a way that the Tesla might not like, but that doesn't seem to be the case, at least on my smallish partitions. That might still be a factor if your music partition is bigger, though.) My procedure, both times:
  1. I plugged the USB drive in and ensured that no partition from the USB drive was mounted.
  2. I partitioned the USB drive to have a single partition, using the MBR partition table, and set the partition's type code to 0x83.
  3. I created an ext4 filesystem on the drive with "sudo mkfs -t ext4 /dev/sdi1" (or "/dev/sdc1"; I used two different computers, so the USB drives showed up with different identifiers).
  4. I mounted the partition to /mnt.
  5. I typed "sudo chmod 0777 /mnt" to ensure that all users have full read/write access to the drive.
  6. I copied two directories with music, in MP3 format, to the drive.
  7. I unmounted the drive.
  8. I took the drive to my car and plugged it in.
  9. I used the Tesla's music app to look for music on the USB device. This worked both times.
  10. I successfully played music from the drive.
I suggest you try the above procedure as exactly as possible, using an 8-16GB USB drive, Ubuntu 18.04 or 19.10, and a small number of music files. To begin, use one MBR partition; don't try to start with a device that's partitioned for both Sentry Mode and music use. If you can get this to work, then begin deviating in the direction of whatever did not work -- multiple partitions, a larger USB drive, GPT, more music files, or whatever. Change one variable at a time. In that way, you'll either end up with a working configuration or you'll have discovered what's causing the problem.

FWIW, my car just upgraded to 2019.36.2.1 last night.
Thanks for posting your method. I was running Ubuntu 18.04 when I set up my drive as well but used the gui disk manager instead of doing it command line.

I initially tried two ext4 partitions so I could use TeslaCam as well but the USB icon didn't show up for the MP3s. I also tried a single ext4 partition with MP3s and got the same result. In the end I used ext4 for partition 1 with TeslaCam and FAT32 for partition 2 and music and it's been working fine. I'll give your steps a try next time I pull the drive though.
 
Check your permissions on the filesystem and on the files. I don't recall the details, but I do recall seeing a post in which it was claimed that the permissions had to be set quite permissively to enable TeslaCam to operate. The same may be true for reading music files. I'd try this:
  1. Mount the USB drive partition you want somewhere, say /mnt.
  2. As root or via sudo:
    1. chmod 0777 /mnt
    2. chmod -R a+rw /mnt/*
Note the above is from my head. I haven't tested it, so it may contain errors. The idea is to change the permissions of the filesystem itself (at /mnt) so that anybody can read from and write to it; and add read and write permissions for all users to all files and directories on the filesystem. (For the music player, write permissions should not be needed, but read permissions are.)

I've just done some testing (bash-fu'd 2001 directories with a mp3 in each and each one a different uid:gid in the range of 0..2000) and found that while uid:gid 1002 and 1111 could see the files they couldn't be played, but both 28 and 29 seemed to work.

So in theory can do something like this :

1) chmod 0777 /mnt
2) chown -R 28:28 /mnt/*
3) chmod -R 0750 /mnt/*

And it should work

Alternatively you can be a bit fancier and do something like the following for step 3 if you are particular about non-executable files being marked executable:
find /mnt -type d -exec chmod 750 {}
find /mnt -type f -exec chmod 640 {}

I haven't tried putting music and cam on the same partition yet, this was separate partitions, but that'll be the next thing to try ...
 
2) chown -R 28:28 /mnt/*
3) chmod -R 0750 /mnt/*
[...]
find /mnt -type d -exec chmod 750 {}
find /mnt -type f -exec chmod 640 {}


Yikes! Please be aware that this will mess with the permissions of all mounted drives/partitions, and not just the USB stick you're looking to modify. Be careful -- very careful -- when wielding recursive commands and wildcards, friends!

2) chown -R 28:28
I've read (and seen!) that the Tesla, in a nod to Orwell, uses UID/GID 1984 for its Teslacam and Sentry directories and files on ext4 filesystems. Where did you get UID/GID 28 from?
 
It works fine with the correct file permissions, but unless you have a very large drive (256GB or more) there's no advantage to using ext4 on the music partition, which is read-only in the car.

For TeslaCam/sentry, keep in mind ext4's journaling makes it resistant to sudden disconnection, but the tradeoff is more wear on the flash media. I recommend setting the journal to writeback mode. This allows max performance while protecting from corruption, but may discard recently written data if the drive is disconnected suddenly. The command is: tune2fs -o journal_data_writeback <device>
 
Yikes! Please be aware that this will mess with the permissions of all mounted drives/partitions, and not just the USB stick you're looking to modify. Be careful -- very careful -- when wielding recursive commands and wildcards, friends!


I've read (and seen!) that the Tesla, in a nod to Orwell, uses UID/GID 1984 for its Teslacam and Sentry directories and files on ext4 filesystems. Where did you get UID/GID 28 from?
Well, I was assuming the music partition was mounted at /mnt, based on the previous comment I was replying to, but I suppose it would be wise to warn people about making assumptions (if you have many things under /mnt/X, /mnt/Y, etc, yes, this would bork them all)

To be more technically correct, it will change the permissions of anything mounted at /mnt or anything below it in the filesystem tree.

It won't affect literally all mounted filesystems as not all of them are mounted at /mnt (i.e., the root filesystem is mounted at /, you might have a separate /boot or /home, and so on).
It works fine with the correct file permissions, but unless you have a very large drive (256GB or more) there's no advantage to using ext4 on the music partition, which is read-only in the car.

For TeslaCam/sentry, keep in mind ext4's journaling makes it resistant to sudden disconnection, but the tradeoff is more wear on the flash media. I recommend setting the journal to writeback mode. This allows max performance while protecting from corruption, but may discard recently written data if the drive is disconnected suddenly. The command is: tune2fs -o journal_data_writeback <device>

If I get around to it I want to try doing a TeslaUSB gizmo that instead of using FAT32 uses ext and LVM snapshots to make the process of managing the music library and teslacam videos smoother. I've done some manual experiments with a Pi 4 attached to my Linux box at home, haven't actually tested the process in the car, and haven't fully fleshed out the code to do things...

I will say that ext4 (and probably 2/3) find / browse the music much faster than FAT32, at least in my experience. Even with just a 32GB drive.
 
It's entirely possible that if your Science bears tasty fruit, that Marcone might welcome a pull request making this an option.
If I get around to actually making something releasable, it probably won't be submitted as a PR to the existing repo. I'm going in a very different direction design wise (both different implementations of existing features and entirely new features) and using basically nothing from the existing projects (other than as sources of information and guides of how it's been done before). That's not to say a PR couldn't be made, but it would basically erase everything that was already there and replace it with something entirely different. There's more differences than LVMs :) I haven't worked on it for a month or two though... no telling when I'll get back into it for any useful length of time. I was originally cobbling together some rudimentary functionality with a mixture of bash, python, and PHP, just for general testing and fleshing out of ideas, then started over to do everything "properly" using just python with Flask (both because it would in the end be a less convoluted solution, and also to learn Flask as I have only ever used PHP for web stuff).
 
It works fine with the correct file permissions, but unless you have a very large drive (256GB or more) there's no advantage to using ext4 on the music partition, which is read-only in the car.
One small advantage that ext4 provides for a music partition is very fast cataloging of the files - much faster than a fat32 volume. Of course once that part is done, yes, there is really very little practical advantage that ext4 has.
 
  • Helpful
Reactions: BioSehnsucht
If I get around to actually making something releasable, it probably won't be submitted as a PR to the existing repo. I'm going in a very different direction design wise (both different implementations of existing features and entirely new features) and using basically nothing from the existing projects (other than as sources of information and guides of how it's been done before). That's not to say a PR couldn't be made, but it would basically erase everything that was already there and replace it with something entirely different. There's more differences than LVMs :) I haven't worked on it for a month or two though... no telling when I'll get back into it for any useful length of time. I was originally cobbling together some rudimentary functionality with a mixture of bash, python, and PHP, just for general testing and fleshing out of ideas, then started over to do everything "properly" using just python with Flask (both because it would in the end be a less convoluted solution, and also to learn Flask as I have only ever used PHP for web stuff).
Well if it ends up going well enough that you need some guinea pigs, I might be happy to help - depending on the feature set :)