Crouton: The default shared folder (Downloads) is broken
name: xenial
encrypted: no
Entering /mnt/stateful_partition/crouton/chroots/xenial...
crouton: version 1-20171122220410~master:99877eaf
release: xenial
architecture: arm64
xmethod: xiwi
targets: keyboard,xiwi,core
host: version 10230.0.0 (Official Build) dev-channel elm
kernel: Linux grischrome 3.18.0-16380-ged556dd88087-dirty #1 SMP PREEMPT Tue Dec 19 11:13:48 PST 2017 aarch64 aarch64 aarch64 GNU/Linux
freon: yes
My issue:
When I enter into the chroot the downloads folder is mounted (no error reported about something that went wrong when you run sudo enter-chroot))
I've done all the googles Updates im on an acer R13 Chromebook, I also tried to update the chroot using crouton -u but I give you the output of ls -l and nothing happens
The steps to see nothing in the :
chronos@localhost ~/Downloads $ sudo enter-chroot
Entering /mnt/stateful_partition/crouton/chroots/xenial...
(xenial)bertrand@grischrome:~$ ls -lrt Downloads/
total 0
(xenial)bertrand@grischrome:~$ ls -lrtd Downloads/
drwxr-xr-x. 2 root root 4096 avril 9 2017 Downloads/
(xenial)bertrand@grischrome:~$ ls -lrtd Downloads
drwxr-xr-x. 2 root root 4096 avril 9 2017 Downloads
(xenial)bertrand@grischrome:~$ pwd
/home/bertrand
(xenial)bertrand@grischrome:~$ logout
Unmounting /mnt/stateful_partition/crouton/chroots/xenial...
Sending SIGTERM to processes under /mnt/stateful_partition/crouton/chroots/xenial...
chronos@localhost ~/Downloads $ pwd
/home/chronos/user/Downloads
chronos@localhost ~/Downloads $ ls -lrta |tail
-rw-r--r--. 1 chronos chronos 5363 Dec 23 01:30 test.html
-rw-r--r--. 1 chronos chronos 44909 Dec 24 12:08 somefile.svg
-rw-r--r--. 1 chronos chronos 21466 Dec 24 22:21 someotherfile.xml
Bbertatum
All 13 comments
@Bbertatum,
It looks like your chroot is using the latest available version.
Maybe your 'host-bin' files didn't get updated for some reason.
Enter the following in a CrOS shell session and show us what it displays:
cat -n /usr/local/bin/enter-chroot | grep -A 26 '^ *739'
It should look similar to mine shown below:
cat -n /usr/local/bin/enter-chroot | grep -A 26 '^ *739'
739 print "error"
740 print "Invalid syntax in /etc/crouton/shares on line " NR ":\n " \
741 $0
742 }
743 ' "$shares" | while read -r src && read -r dest && read -r opts; do
744 line="\n \"$src\" \"$dest\" $opts"
745 # Expand src
746 case "${src%%/*}" in
747 download|downloads)
748 if [ -z "$localdownloads" ]; then
749 echo "Not mounting share (no Chromium OS user):$line" 1>&2
750 continue
751 fi
752 src="$localdownloads/${src#*/}";;
753 encrypt|encrypted)
754 if [ -z "$localencrypted" ]; then
755 echo "Not mounting share (no Chromium OS user):$line" 1>&2
756 continue
757 fi
758 src="$localencrypted/${src#*/}";;
759 share|shares|shared)
760 src="$localshare/${src#*/}";;
761 error)
762 # Print the error message from awk script.
763 echo "$dest" 1>&2
764 echo "$opts" 1>&2
765 continue;;
In that output line 741 should show: '$0' not '$0 > "/dev/stderr"'
And lines 762-765 should display:
761 error)
762 # Print the error message from awk script.
763 echo "$dest" 1>&2
764 echo "$opts" 1>&2
765 continue;;
like mine above.
If your display doesn't look like mine you may need to reboot and then restore the 'host-bin' files using:
sudo sh ~/Downloads/crouton -b
Hope this helps,
-DennisLfromGA
DennisLfromGA
on 27 Dec 2017
It looks like exactly the same :
print "error"
print "Invalid syntax in /etc/crouton/shares on line " NR ":\n " \
$0
}
' "$shares" | while read -r src && read -r dest && read -r opts; do
line="\n \"$src\" \"$dest\" $opts"
# Expand src
case "${src%%/*}" in
download|downloads)
if [ -z "$localdownloads" ]; then
echo "Not mounting share (no Chromium OS user):$line" 1>&2
continue
fi
src="$localdownloads/${src#*/}";;
encrypt|encrypted)
if [ -z "$localencrypted" ]; then
echo "Not mounting share (no Chromium OS user):$line" 1>&2
continue
fi
src="$localencrypted/${src#*/}";;
share|shares|shared)
src="$localshare/${src#*/}";;
error)
# Print the error message from awk script.
echo "$dest" 1>&2
echo "$opts" 1>&2
continue;;
I'll try to reset the "host-bin" files...
Thanks for the quick reply :)
Bbertatum
on 27 Dec 2017
I'm in the same situation, except I haven't updated my chroot in a while (and, since the shared folder isn't sharing, I can't update using the instructions in the README which rely on it). Current version is 1-20170619181610~master:980f090f according to croutonversion -u. The output of your suggested command is slightly different for me:
chronos@localhost / $ cat -n /usr/local/bin/enter-chroot | grep -A 26 '^ *739'
739 print "Invalid syntax in /etc/crouton/shares on line " NR ":\n " \
740 $0 > "/dev/stderr"
741 }
742 ' "$shares" | while read -r src && read -r dest && read -r opts; do
743 line="\n \"$src\" \"$dest\" $opts"
744 # Expand src
745 case "${src%%/*}" in
746 download|downloads)
747 if [ -z "$localdownloads" ]; then
748 echo "Not mounting share (no Chromium OS user):$line" 1>&2
749 continue
750 fi
751 src="$localdownloads/${src#*/}";;
752 encrypt|encrypted)
753 if [ -z "$localencrypted" ]; then
754 echo "Not mounting share (no Chromium OS user):$line" 1>&2
755 continue
756 fi
757 src="$localencrypted/${src#*/}";;
758 share|shares|shared)
759 src="$localshare/${src#*/}";;
760 *)
761 echo "Invalid share:$line" 1>&2
762 continue;;
763 esac
764 # Expand dest for homedirs
765 if [ "${dest#"~"}" != "$dest" ]; then
Should that suggested fix work on my version?
(if it's relevant, starting the chroot has for the last few days produced:
Entering /mnt/stateful_partition/crouton/chroots/xenial...
awk: run time error: redirection not allowed in sandbox mode
FILENAME="" FNR=0 NR=0
but I don't know whether it started at the same time as the shared Downloads disappearing, because I haven't tried to use the shared Downloads from the chroot in a while)
qwertystop
on 27 Dec 2017
I can report that in my case, the issue was fixed when I used my existing version of crouton to update xiwi and install unity, sudo sh ~/Downloads/crouton -t xiwi,unity -u -n xenial.
qwertystop
on 27 Dec 2017
@Bbertatum are you using multi-login? See #1410 and #3531
dnschneid
on 27 Dec 2017
@Bbertatum,
kernel: Linux grischrome ....
Did you rename your chroot's hostname from 'localhost' to 'grischrome' ?
CrOS doesn't play nice when the hostname is changed but I can't say I've tried it in a chroot recently.
-DennisLfromGA
DennisLfromGA
on 27 Dec 2017
I'm not using multi-login and I made the change (localhost to grischrome) after the issue occurs. Also, I noticed the moment the issue occured I've the same output mentionned before :
Entering /mnt/stateful_partition/crouton/chroots/xenial...
awk: run time error: redirection not allowed in sandbox mode
FILENAME="" FNR=0 NR=0
After updating the chroot the message is no more poppin but the folder seems not to be mounted :(
@dnschneid Is there a way to troubleshoot deeply this problem ? I can't figure how the mount is done... I tried to mount directory using --bind but this always mount the entire partition instead of directory. Is there a command I can try to mount the directory inside chroot after I issue the command : "sudo enter-chroot"
Thanks
Bbertatum
on 28 Dec 2017
@DennisLfromGA : As adviced I update "host-bin" runnin :
sudo sh ~/Downloads/crouton -b
With no luck :
chronos@localhost / $ sudo enter-chroot
Entering /mnt/stateful_partition/crouton/chroots/xenial...
(xenial)bertrand@localhost:~$ ls -lrt Downloads/
total 0
(xenial)bertrand@localhost:~$
Also, as u can see after a reboot, the setting of the hostname has been reset.
Bbertatum
on 28 Dec 2017
@Bbertatum,
Okay, thanx, just trying to remove some variables to eliminate any interaction with this issue.
Also, I noticed the moment the issue occured I've the same output mentionned before :
Entering /mnt/stateful_partition/crouton/chroots/xenial...
awk: run time error: redirection not allowed in sandbox mode
FILENAME="" FNR=0 NR=0
Is it possible you have more than one enter-chroot in your PATH, one that is older perhaps?
I use something like the following to get more diagnostic output:
sudo sh -x /usr/local/bin/enter-chroot -n xenial 2>&1 | tee /tmp/enter-chroot.out
The devs may have a better suggestion though.
Hope this helps,
-DennisLfromGA
DennisLfromGA
on 28 Dec 2017
This change came about with ChromeOS upgrading to v64. That may help some as well.
stephengale801
on 5 Jan 2018
@stephengale801 : Is there a way to get back normal behaviour with the share ?
I forgot to mention that I set up the chromebook in "Beta mode" to get GooglePlay apps.... But at the beggining there was no problem with the share that comes suddenly.
Bbertatum
on 6 Jan 2018
I just had this issue and running the update command from the CRoSh (sp? [ChrOSh? {Whatever, the shell before you type sudo enter-chroot \ sudo sh ~/Downloads/crouton -n
CrypticCalamari
on 10 Mar 2018
Following @CrypticCalamari I did this:
sudo sh ~/Downloads/crouton -n -u
but that alone didn't bring back my Downloads shared directory. But then doing this (thank you @Bbertatum ) did solve it:
sudo sh ~/Downloads/crouton -b
Thank you all.
bwdugan
on 16 Mar 2018
Related issues
jvschiavo
路
4Comments
tedm
路
3Comments
Taylormsz
路
5Comments
BRFNGRNBWS
路
3Comments
rossjrw
路
5Comments
Most helpful comment
@Bbertatum,
It looks like your chroot is using the latest available version.
Maybe your 'host-bin' files didn't get updated for some reason.
Enter the following in a CrOS shell session and show us what it displays:
cat -n /usr/local/bin/enter-chroot | grep -A 26 '^ *739'It should look similar to mine shown below:
In that output line 741 should show: '
$0' not '$0 > "/dev/stderr"'And lines 762-765 should display:
like mine above.
If your display doesn't look like mine you may need to reboot and then restore the 'host-bin' files using:
sudo sh ~/Downloads/crouton -bHope this helps,
-DennisLfromGA