Giving [rw] access to the microSD and config the /mnt/userrw/sdcard path as base dir.
After performs fopen , fwrite, fread, fclose the file always is created in /mnt/flash/legato/systems/current/appsWriteable/myApp/ intead of /mnt/userrw/sdcard
Checking the permissions for /mnt/userrw/sdcard , always get drwxr-xr-x, and doing chmod never configures as rw in user.
I´ve tested with the le_fs and the files are created outside microSD too.
I’m curious about this too. I’ve never been able to get an SD card working with an app running in sandbox mode (sandboxing apps is what creates the path discrepancy you mentioned). If you modify your .adef file to specifysandboxed: false and remove the dir clause, this will work if the SD card is mounted. In terms of auto mounting, you can modify /etc/fstab or invoke mount calls in your code. This does however come at the cost of some security, so hopefully there is a way to achieve this in sandbox mode.
I believe this issue has come up before, but my memory is a bit hazy on the details. Firstly, it is not necessary to have the requires device line in your adef. Typically you would format the SD card with a filesystem and then mount it somewhere. When you write a file on the filesystem, the kernel is accessing the underlying block device on your behalf so you don’t need read/write permissions on the raw device yourself. What you do need is permission to read/write the files/directories on the SD card’s filesystem.
–EDIT
The main problem is that when you do a requires dir, the existing files from that location are bind mounted into the sandbox. So assuming you have permission, you can read or write those files from within the sandbox. The problem is that when you create a new file, it isn’t created in the SD card filesystem. It’s created within the sandbox directory of the app. As an example from the command line, you could create an empty log.txt file on your SD card and then start a sandbox app that does requires dir on the SD card mount point. Then that sandboxed app could open the file and write to it. The writes would be stored on the SD card because the file that was opened is actually on the SD card.
What I said in the previous paragraph is mostly true, but I haven’t talked about SMACK yet. Every sandboxed app has a smack label. An app Logger has the smack label app.Logger. When you try to open log.txt for writing, SMACK may prevent that from succeeding. SMACK has the concept of each file having a label. This label may be set in the extended attributes of the filesystem or it may be applied as a default based on the mount options that were passed when mounting the filesystem. FAT filesystems (often used on SD cards) don’t support extended attributes. If you mount the filesystem with a default smack label that matches your app’s smack label, then the app will be able to access the log.txt file on the SD card.
Here’s a test I did:
Format my SD card with a FAT filesystem in Windows
Insert my SD card into my mangOH red and powered it up
Mount my SD card with very permissive file permissions and an assigned default smack label of “sd”: mount -ofmask=0111 -odmask=0000 -osmackfsdef=sd /dev/mmcblk0p1 /etc/sd/
Create a file on the SD card: touch /etc/sd/log.txt
Create a smack rule which allows the app “myApp” to read, write and append to files with the “sd” smack label: echo "app.myApp sd rwa" > /legato/smack/load2
Simulate the environment the app is running under: echo "app.myApp sd rwa" > /legato/smack/load2 && su -s /bin/sh appmyApp
Append to the log file: echo foo >> /etc/sd/log.txt
Run exit to exit from the appmyApp user shell
Run cat /etc/sd/log.txt and verify that the “foo” content is in the file.
The smack rules don’t persist across reboots. Supposedly you can write rules into /etc/smack/accesses, but I haven’t tried that yet.
Hi,
I followed the steps below because my app can only change SD card files in case I use ‘sandboxed: false’ in my .adef file.
Insert my SD card into my mangOH green and powered it up
Mount my SD card and an assigned default smack label of “sd”: mount -ofmask=0111 -odmask=0000 -osmackfsdef=sd /dev/mmcblk0p1 /etc/sd/
Apparently, this creates a subfolder /etc/sd/sd/.
Is this normal behaviour?
Create a smack rule which allows the app “myApp” to read, write and append to files with the “sd” smack label: echo "app.myApp sd rwa" > /legato/smack/load2
I checked the content of the load2 file: my smack rule is there
Put this line into my app source code:
FilePtr = fopen("/etc/sd/temp.txt", “a”);
Build and install my app with ‘sandboxed: true’
FilePtr is always NULL, and error details tell me ‘No such file or directory’.
Any idea what is going wrong?
Are there any tutorials or demos on SD card implementation?
@amil13 If you are using a WPxxxx module and you’re on the Linux processor, it’s easy to tell if the card is detected. If there’s a /dev/mmcblk0 device, the card was detected. If it’s missing, then it wasn’t. I’m not sure if there’s a Legato API for that or not, but the standard Linux POSIX calls can do it.
Hey @fgodfrey !! Thank you so much for replying!! I am using WP7607 and yes i can see the /dev/mmcblk0 which means that the card is detected. but what is up with mounting it and all??and I will look into the Linux Posix calls as well!!!
If you have any other information ,maybe a demo program for writing or reading in the sd card, please share , i’d be greatful to you!! =)
I am just using standard Linux, not Legato, in my project so reads and writes work just like any file access.
As for your mount command, get rid of the “-t” option and what you’re doing should work, assuming /mnt/amilrw/sdcard_ exists. The “-t” is causing it to tread /dev/mmcblk0p1 as the filesystem type, not the path to the device. Then, since you didn’t give a path to the device (because it thinks that’s the type due to -t), it tries to look up the filesystem in /etc/fstab to figure out what device to mount.
The “-t” is to specify a filesystem type which used to be absolutely required, but Linux has gotten quite smart at inferring the type over the years and so it shouldn’t be necessary.
