Responding to #c12: Sorry Daniel, I only just noticed your question now. The plan is to make this feature available to be able to share Drive, Play files, and removable drives. The term 'provided' filesystem has a special meaning for FilesApp. We wont be sharing filesystems that are implemented as https://developer.chrome.com/apps/fileSystemProvider.
@74 - I would like to see both. Drive is great but I am not sure how it would work when the Chromebook is offline. The Downloads, External Storage (MicroSD/USB Flash Drives, USB Hard Drives), Network Shares (FTP, NTFS, SSH, NFS and SMB) and Google Drive.
@75 You can always set important files to be available offline.
ChromeOS is based on Cloud principles and having to manually sync files to google drive is not something practical.
I believe Downloads was supposed to be something "temporary" and, although most higher end chromebooks do have enough storage, I believe the best approach is to save on cloud with offline availability managed by the OS and not the user.
Do you want anecdotal data posted here regarding things that don't work (and stuff that does) when trying to use the sd card from linux apps, or is it premature?
ok,
here's one that is either a permission issue, or illustrates that I misunderstand something about rsync.
rsync creates an error when you try to create a log file on the sd card. If the log file already exists, it will append to it. If the log file doesn't exist, you get a permission error. Note that rsync will create files for the sync part of the operation, just not a log file.
Here's an example of an rsync that works to copy files, but also creates an error in regard to the log file:
rsync -rtogvO --progress \
--log-file=/mnt/chromeos/removable/<SDcard>/testfolder/testlog.txt \
/home/<username>/testfolder/ \
/mnt/chromeos/removable/<SDcard>/testfolder/
Here is the error:
sync: failed to open log-file /mnt/chromeos/removable/<SDcard>/testlog.txt:
Invalid argument (22)
Ignoring "log file" setting.
Which particular folder did you share in this case? Is it visible at chrome://settings/crostini/sharedPaths?
It looks like you might have shared the 'testfolder' in <SDcard>, and rsync is trying to access a file in the root of the sdcard which is not accessible?
No, I shared the sd card root. Attached is a screenshot of my sharedpaths
What's happening is that rsync will create the files it needs to do the sync on the "share with linux" folders. It will create the log file in the linux user's home folder as the destination (/home/<user>). It just can't create the log-file in one of the "share with linux" folders.
Deleted:
Screenshot 2018-12-02 at 21.59.30.png
18.2 KB
Here's a screenshot showing the rsync command causing an error trying to create the log-file.
Next the touch command manually creates the log-file.
Then the same rsync command will work and append log data to the file that now exists,
Deleted:
Screenshot 2018-12-02 at 22.35.55.png
97.6 KB
One issue that I've run into is if I share a folder on a removable device (like a USB connected SSD), if I start crostini while the device isn't plugged in the folder doesn't get shared. I can't figure out how to add those devices from termina using lxc commands either since those seem to operate on the assumption I'm sharing a folder in Downloads. Ideally I'd like those folders to show up when I plug in the device, either automatically or somehow being able to force a refresh without restarting the container.
Ah, one other thing is that if I mv a file from crostini to the shared folder, I'll see messages about insufficient permissions but it will still work. Further changes after the file already exists in the shared folder don't raise any permission complaints.
You would be able to share the removable device by unsharing in the settings page, then sharing again via FilesApp, or restarting the vm. You are correct that 'vmc share' only supports Downloads. Support for detecting new mounts in the system after the vm has started and then sharing those mounts can be tracked in issue 908289 .
I have created issue 912599 to track #c123, but this is expected since we don't allow chmod operations on shared folders.
I have another example of permissions stuff in regard to crostini and sd cards I can document for you.
I will point out at the outset that both of my devices are still on 72.0.3609.3. For some reason coral and fizz have not yet rolled to 72.0.3623.3.
Here's the data. On my coral device (Lenovo 500e), read/write/execute access is all turned on.
On my fizz device (HP Chromebox G2) write access is off.
See the attached screenshots for each.
Also note that even though these are both default crostini setups, they display differently. I have not altered any environment/shell settings - note the color differences.
Hope this is helpful.
Turns out the color difference is actually BECAUSE of the permissions difference. The bash setup in crostini gives "other-writable" folders a green background.
So the only thing to figure out is why coral has user, group and other folders as writable and fizz has none of them as writable.
