switch - access denied when trying to mount NAS share for roms etc.

[jdalmanza]

when following the steps to mount a NAS share for roms as described in the lakka documentation:
https://www.lakka.tv/doc/Serving-ROMs-from-a-NAS/

When you reach the step to enable the storage-{path}.mount service you get an Access denied error:

Lakka:~ # systemctl enable storage-nas.mount
Failed to enable unit: Access denied

This issue is present on 4.3 and still an issue in the 5.x nightly builds (tested on 15-JAN nightly build)

[Ntemis]

Thank you for the report!

[jdalmanza]

@Ntemis , i tried this on the 17-JAN build and got he same results
logset attached, please let me know if you need anything else
log-2024-01-24-00.51.52.zip

[synthic]

Searching for this issue yields results relating to selinux, but I don't think that applies here. Still, you can try to run systemctl daemon-reexec before the enable command and see if that helps.

[jdalmanza]

lakka (official): devel-20240123161432-37de45a (Switch.aarch64)

lakka-switch:~ # ls /storage/.config/system.d/
README multi-user.target.wants openvpn.service.sample
cifs.mount.sample nfs.mount.sample storage-nas.mount
lakka-switch:~ # systemctl daemon-reexec
lakka-switch:~ # systemctl enable storage-nas.mount
Failed to enable unit: Access denied

lakka-switch:~ # cat /storage/.config/system.d/storage-nas.mount
[Unit]
Description=cifs mount script
Requires=network-online.service
After=network-online.service
Before=retroarch.service

[Mount]
What=//xxx.xxx.xxx.xxx/retroarch
Where=/storage/nas
Options=username=xxx,password=xxx,rw
Type=cifs

[Install]
WantedBy=multi-user.target
lakka-switch:~ #

@synthic
This exact file works on all my other lakka devices 4.3 and 5.x the switch build is the only one that fails

[Ntemis]

ow! missed the switch part. Reopening and assigning to the proper person

[GavinDarkglider]

lakka (official): devel-20240123161432-37de45a (Switch.aarch64)

lakka-switch:~ # ls /storage/.config/system.d/ README multi-user.target.wants openvpn.service.sample cifs.mount.sample nfs.mount.sample storage-nas.mount lakka-switch:~ # systemctl daemon-reexec lakka-switch:~ # systemctl enable storage-nas.mount Failed to enable unit: Access denied

lakka-switch:~ # cat /storage/.config/system.d/storage-nas.mount [Unit] Description=cifs mount script Requires=network-online.service After=network-online.service Before=retroarch.service

[Mount] What=//xxx.xxx.xxx.xxx/retroarch Where=/storage/nas Options=username=xxx,password=xxx,rw Type=cifs

[Install] WantedBy=multi-user.target lakka-switch:~ #

@synthic This exact file works on all my other lakka devices 4.3 and 5.x the switch build is the only one that fails

This works for me, just need to set protocol version in options line..... testing against samba version packaged in libreelec/lakka, the needed protocol version is 2.1, though that is depending on your server.

Options=username=xxx,password=xxx,rw,vers=2.1 was the only required change

Oh, I missed the enable part..... yeah, no idea why that isnt working, though if I had to guess, it has to do with the fact it is trying to change permissions on a file on a fat partition, which it cant.

you can start the service manually, but probably will never be able to enable it on boot, due to this limitation, without creating a new image, and including the mount in the image.....

Actually.... I might be able to work around this issue, though, I cant promise it will work, if it tries to connect mount before wifi comes up, I would still expect it to fail on boot.

[GavinDarkglider]

Ok, figured out what is going on here....... Not really sure how to fix it properly though..... I might be able to hack something together, but this comes down to how systemd enables services(Creates Symlinks in a bunch of folders, to the service/mount file). Unfortunatly, fat32/exfat do not support symbolic links at all, hince the access denied when trying to enable it.

This issue has probably existed since the first version of lakka on the switch(Before I re-ported/upstreamed), and no one noticed it, because no one else was trying to add systemd unit files to storage and enable them. lol.

That being said, I am going to test some stuff, and see if I can work around the issue for you, probably wont be the cleanest fix ever, but the other option is moving storage to a proper linux partition on the SDcard which kind of ruins the magic of what lakka does for the average switch user. That and for something like libreelec, that will be absolutly needed for things like VPN bring up...... so .....

[jdalmanza]

actually that makes a lot of sense about the symlinks.
So, let's say that the switch version cannot mount a nas share like a service as the other builds do, how hard would it be to offer an easy way to easily mount a cifs/samba share via the gui. i figure folks that know what they are doing can probably mount manually via the command line or even maybe edit the fstab if that is allowed.
I'm willing to close this out with that explanation as-is and maybe turn it into a feature request for a gui enabled nas mount function?

[GavinDarkglider]

actually that makes a lot of sense about the symlinks. So, let's say that the switch version cannot mount a nas share like a service as the other builds do, how hard would it be to offer an easy way to easily mount a cifs/samba share via the gui. i figure folks that know what they are doing can probably mount manually via the command line or even maybe edit the fstab if that is allowed. I'm willing to close this out with that explanation as-is and maybe turn it into a feature request for a gui enabled nas mount function?

The reality is, this should be fixed, to keep uniformity with all builds. While I agree with you this should be added to the gui, which is also possible, and then have it start the services for systemd, if the user enables them at boot time......

that is kind of a dirty hack though. Currently, you should be able to use the mount file you created....... systemctl start storage-nas.mount you just cant set it to start on boot.

[GavinDarkglider]

The not so pretty way to work around this would be to call a script in this file: https://github.com/libretro/Lakka-LibreELEC/blob/Lakka-v5.x/packages/lakka/retroarch_base/retroarch/scripts/retroarch-config

then you can put the systemctl command in a script on your sdcard, and still start it before retroarch starts. That being said, it would still need a new image, so let me play with some more messed up, but also more uniform options, that might fix the issue, as that would be ideal.

The more uniform way is to see if mergerfs's newish symlink support works across file systems, and to do some trickery in initramfs...... in which case, I can create the symlinks in an ext4 based image, and overlay the filesystems like we do with the retroarch configs. which in therory should "properly" fix the issue. Assuming I understand how this new support actually works. lol.

[whmzsu]

Is there any options to set with mount to support Unicode charsets like CJK with the default fat32 partition or other new partitions ??

[shea-sollars]

If you run journalctl storage-nas.mount (or whatever the name of your .mount file is), you'll see it complaining about the file being executable when it shouldn't be. Unfortunately, you cannot remove the executable flag on a file stored in a FAT32 partition.

A possible workaround is to unsquash the SYSTEM file from Linux (avoid using WSL on Windows, as it wrecks the file permissions for the entire filesystem), add the .mount file to the appropriate folder, and then squash it back up. This will successfully automount the share, but it mounts as root instead of lakka, meaning you won't be able to save files. Does anyone know how to get it to mount with the proper user?

Here are the steps I follow:

1. Verify that squashfs-tools is installed:

   sudo apt update
   sudo apt install squashfs-tools
   mksquashfs --version
   

2. Extract the Lakka-Switch.aarch64-5.0.tar file:

   cd Lakka-Switch.aarch64-5.0
   

3. Unsquash the SYSTEM file:

   mkdir custom
   sudo unsquashfs -d custom/unsquashed lakka/SYSTEM
   

   (Requires sudo to preserve root ownership of the files.)
4. Edit the .mount file: (adjusting filename)

   sudo nano custom/unsquashed/usr/lib/systemd/system/storage-DSM-Media.mount
   

   Paste the following content adjusting directory/What/Where, username, and password:

   [Unit]
   Description=CIFS mount for NAS
   Requires=network-online.service
   After=network-online.service
   Before=retroarch.service
   
   [Mount]
   What=//192.168.1.101/Media
   Where=/storage/DSM/Media
   Options=username=....,password=....,rw,vers=2.0,uid=1000,gid=1000,forceuid,forcegid
   Type=cifs
   
   [Install]
   WantedBy=multi-user.target
   

5. Create the symbolic link for the .mount file:

   sudo ln -s ../storage-DSM-Media.mount custom/unsquashed/usr/lib/systemd/system/multi-user.target/storage-DSM-Media.mount
   

6. Repack the SYSTEM file:

   sudo mksquashfs custom/unsquashed lakka/SYSTEM -comp lzo -b 524288
   

7. Generate the MD5 checksum:

   sudo md5sum lakka/SYSTEM > lakka/SYSTEM.md5
   

8. Replace the existing SYSTEM and SYSTEM.md5 files on your Switch. I use the USB tool in Hekate for this step.

This process will successfully mount the SMB folder at boot. You'll be able to browse the files. However, LibreELEC ignores the uid=1000,gid=1000,forceuid,forcegid options, so the network folder gets mounted as root (uid=0, gid=0). It needs to be mounted as lakka.

If you try to save a game or a state, it will get stuck at "Saving 0%," and you won't be able to restart, reboot, or shut down. You'll have to force power down the Switch and inject the payload to start Hekate again.

I spent an entire weekend figuring this out, so I'm taking a break for now. If someone else can figure out how to overcome the root obstacle, or if this issue gets fixed in LibreELEC, it would be great. Honestly, though, I’m not sure it can be resolved on a FAT32 partition.

My next idea is to add an automount.sh script somewhere in the filesystem, but I’ve already spent too much time on this and lost my motivation.

[GavinDarkglider]

If you run journalctl storage-nas.mount (or whatever the name of your .mount file is), you'll see it complaining about the file being executable when it shouldn't be. Unfortunately, you cannot remove the executable flag on a file stored in a FAT32 partition.

A possible workaround is to unsquash the SYSTEM file from Linux (avoid using WSL on Windows, as it wrecks the file permissions for the entire filesystem), add the .mount file to the appropriate folder, and then squash it back up. This will successfully automount the share, but it mounts as root instead of lakka, meaning you won't be able to save files. Does anyone know how to get it to mount with the proper user?

Here are the steps I follow:

1. Verify that squashfs-tools is installed:

   sudo apt update
   sudo apt install squashfs-tools
   mksquashfs --version
   

2. Extract the Lakka-Switch.aarch64-5.0.tar file:

   cd Lakka-Switch.aarch64-5.0
   

3. Unsquash the SYSTEM file:

   mkdir custom
   sudo unsquashfs -d custom/unsquashed lakka/SYSTEM
   

   (Requires sudo to preserve root ownership of the files.)

4. Edit the .mount file: (adjusting filename)

   sudo nano custom/unsquashed/usr/lib/systemd/system/storage-DSM-Media.mount
   

   Paste the following content adjusting directory/What/Where, username, and password:

   [Unit]
   Description=CIFS mount for NAS
   Requires=network-online.service
   After=network-online.service
   Before=retroarch.service
   
   [Mount]
   What=//192.168.1.101/Media
   Where=/storage/DSM/Media
   Options=username=....,password=....,rw,vers=2.0,uid=1000,gid=1000,forceuid,forcegid
   Type=cifs
   
   [Install]
   WantedBy=multi-user.target
   

5. Create the symbolic link for the .mount file:

   sudo ln -s ../storage-DSM-Media.mount custom/unsquashed/usr/lib/systemd/system/multi-user.target/storage-DSM-Media.mount
   

6. Repack the SYSTEM file:

   sudo mksquashfs custom/unsquashed lakka/SYSTEM -comp lzo -b 524288
   

7. Generate the MD5 checksum:

   sudo md5sum lakka/SYSTEM > lakka/SYSTEM.md5
   

8. Replace the existing SYSTEM and SYSTEM.md5 files on your Switch. I use the USB tool in Hekate for this step.

This process will successfully mount the SMB folder at boot. You'll be able to browse the files. However, LibreELEC ignores the uid=1000,gid=1000,forceuid,forcegid options, so the network folder gets mounted as root (uid=0, gid=0). It needs to be mounted as lakka.

If you try to save a game or a state, it will get stuck at "Saving 0%," and you won't be able to restart, reboot, or shut down. You'll have to force power down the Switch and inject the payload to start Hekate again.

I spent an entire weekend figuring this out, so I'm taking a break for now. If someone else can figure out how to overcome the root obstacle, or if this issue gets fixed in LibreELEC, it would be great. Honestly, though, I’m not sure it can be resolved on a FAT32 partition.

My next idea is to add an automount.sh script somewhere in the filesystem, but I’ve already spent too much time on this and lost my motivation.

While this works, it is not a solution. The real solution is fake permissions via rewritefs, but support needs to be added.....
What you propose needs to be done every update, as the squashfs gets replaced in the process. Also, while it complains about executable permissions, that isn't the issue, the issue is symlinks aren't supported on fat32, so you need to save that info elsewhere, and have rewritefs read in that info for each file in lakka/storage dir. Then it would treat fat32 like ext4.... With caveots, like a db of file data, or a ton of hidden permission files.

It is on my list of things to fix, but I am not coding on a phone/tablet.

Also, this issue effects Kodi add-ons as well, that need to execute apps in the background..... As they try to set execute permissions in the Kodi add-on side, and when it can't, it kills the plugin.... Ironically everything is considered executable anyway. Lol.

[shea-sollars]

I ended up going with a storage-DSM-Media.service file to solve the root/lakka user issue. The service will successfully automount the NAS on startup under the correct lakka user, so that RetroArch can still save games without freezing up.

[Unit]
Description=Mount SMB Share for DSM Media with Correct Ownership
Requires=network-online.service
After=network-online.service
Before=retroarch.service

[Service]
Type=oneshot
ExecStart=/bin/mount -t cifs -o username=....,password=....,rw,uid=1000,gid=1000,vers=2.0,soft,timeo=500 //192.168.1.101/Media /storage/DSM/Media
ExecStop=/bin/umount /storage/DSM/Media
RemainAfterExit=true

[Install]
WantedBy=multi-user.target

Although this seems to work great at home, I am not sure how it is going to behave when I take the Switch on the road to a different network. I would need to use a VPN in that case anyways. In earlier tests, the whole RetroArch interface would freeze up if WiFi is lost, and cause me to have to force it to power down, then go through the whole inject payload routine. Which is not ideal on the go. Knowing that my whole setup purely relies on my local NAS, I would like to at least be able to boot back into Hekate to use the normal Switch games in Atmosphere if the mounted folder becomes inaccessible, without relying on a payload mechanism. So I am brainstorming some sort of watchdog script to make the network folder service more reliable, maybe even auto toggle VPN when needed.

Another issue is that RetroArch likes to revert save/state directories to default if they become inaccessible before saving the config. It's probably done as some sort of nuance with directory permissions. I might make a bug report on that if I can confirm the cause.

I'm still coming up to speed on how the whole project is put together:

For the rewritefs solution, is that something that we need to wait on LibreELEC to implement? If so, I think a possible temporary solution (but still not great) would be to implement a set of simple scripts that checks the storage overlay for a file with some user defined variables that could be used to mount a network folder, and if the file does not exist it should just exit the script. I could probably do that myself to contribute if you don't think it's worth your time, and again, only if the project is relying on LibreELEC to implement rewritefs.

Edit:
I'll figure out how to build Lakka when I find time, and I'm sure it will all become more clear to me then.

[GavinDarkglider]

I ended up going with a storage-DSM-Media.service file to solve the root/lakka user issue. The service will successfully automount the NAS on startup under the correct lakka user, so that RetroArch can still save games without freezing up.

[Unit]
Description=Mount SMB Share for DSM Media with Correct Ownership
Requires=network-online.service
After=network-online.service
Before=retroarch.service

[Service]
Type=oneshot
ExecStart=/bin/mount -t cifs -o username=....,password=....,rw,uid=1000,gid=1000,vers=2.0,soft,timeo=500 //192.168.1.101/Media /storage/DSM/Media
ExecStop=/bin/umount /storage/DSM/Media
RemainAfterExit=true

[Install]
WantedBy=multi-user.target

Although this seems to work great at home, I am not sure how it is going to behave when I take the Switch on the road to a different network. I would need to use a VPN in that case anyways. In earlier tests, the whole RetroArch interface would freeze up if WiFi is lost, and cause me to have to force it to power down, then go through the whole inject payload routine. Which is not ideal on the go. Knowing that my whole setup purely relies on my local NAS, I would like to at least be able to boot back into Hekate to use the normal Switch games in Atmosphere if the mounted folder becomes inaccessible, without relying on a payload mechanism. So I am brainstorming some sort of watchdog script to make the network folder service more reliable, maybe even auto toggle VPN when needed.

Another issue is that RetroArch likes to revert save/state directories to default if they become inaccessible before saving the config. It's probably done as some sort of nuance with directory permissions. I might make a bug report on that if I can confirm the cause.

I'm still coming up to speed on how the whole project is put together:

For the rewritefs solution, is that something that we need to wait on LibreELEC to implement? If so, I think a possible temporary solution (but still not great) would be to implement a set of simple scripts that checks the storage overlay for a file with some user defined variables that could be used to mount a network folder, and if the file does not exist it should just exit the script. I could probably do that myself to contribute if you don't think it's worth your time, and again, only if the project is relying on LibreELEC to implement rewritefs.

Edit: I'll figure out how to build Lakka when I find time, and I'm sure it will all become more clear to me then.

Rewritefs was a hack added to original switch port to make Bluetooth paths work on fat32. This isn't in libreelec, nor is it likely to ever be. It seems to be the only real solution, since the whole idea was to install it as simply as possible, for people that don't want to partition, or want stock and lakka, and don't want the headache.