[SOLVED] SSD Access Issues

[Hwrd69]

I am having issues accessing my SSD with my music library on it. I can get to it, I can read it and play music files, but I cannot change anything. I can't rename files, add directories/files, or delete directories/files. I have tried using a couple of SFTP programs with the same issue. I keep getting Error3 - Permission Denied. I've tried resetting the permissions with no success. Nothing has fixed the issue. 

I am posting it here because when I go back to an older SD card with Volumio on it I am able to do whatever I need to. When I put both the original and a rebuilt Moode SD card in, the problem is back. I don't think it is the player but something in the RPI OS on the image that is or got messed up. Is there something I can check to help get this working again? A config setting or some such?

RPI4
Output is HIFI DAC+
MoOde 9.10 Bookworm
Samsung 2TB SSD

[Tim Curtis]

I'm not familiar with sftp but is there any configuration thats required on the Pi OS?

[Tim Curtis]

In the auto-mount conf file (/etc/udisks-glue.conf) the permissions mask assigned to Fat32 and NTFS drives is 0022 which translates to the permissions and ownership below. 

Code:

Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)

This permission block has three parts: Owner:drwx Group:r-x Other:r-x meaning Owner has read/write/execute, Group has Read/Execute and All Other Users also have Read/Execute. Owner = root, Group = root.

This basically means that with the above permissions root access is required to write to the drive. There is no root user defined on moode images for obvious security reasons. To get root access to files one must explicitly prefix local commands with sudo or the connecting sftp client for example FileZilla must do this. 

In a quick test with FileZilla on my Mac there is no option for root access using sftp protocol. It connects using the user id and password you set in the Pi Imager when the image was created.

Here's what can be done providing your drives are formatted as either Fat32 or NTFS. Edit the file /etc/udisks-glue.conf (below) and change dmask and fmask from 0022 to 0000. Reboot and the drives will have the following permissions which provide Read/Write/Execute access for Owner, Group and All Other Users.

Code:

Access: (0777/drwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)

/etc/udisks-glue.conf

Code:

match vfatdisks {
    automount = true
    automount_options = {noexec,nodev,noatime,nodiratime,'dmask=0022','fmask=0022'}
    post_mount_command = '/var/www/util/automount.sh add_mount_udisks "%mount_point"'
    post_unmount_command = '/var/www/util/automount.sh remove_mount_udisks "%mount_point"'
}

match ntfsdisks {
    automount = true
    automount_options = {noexec,nodev,noatime,nodiratime,'dmask=0022','fmask=0022'}
    post_mount_command = '/var/www/util/automount.sh add_mount_udisks "%mount_point"'
    post_unmount_command = '/var/www/util/automount.sh remove_mount_udisks "%mount_point"'
}

[TheOldPresbyope]

@Hwrd69 

First of all, moOde and Volumio are different animals. Comparing their behavior here is pointless.

Second, AFAIK, using sftp you have to connect to your moOde player with the player's default username and password. Trouble is, the music sources such as /media/<your SSD mount-name> are mounted as owner root:root and your default user can't modify anything on them directly. 

When you're logged directly into moOde you get around this by invoking the sudo command (you can look it up if this is new to you). The conundrum is how to do it remotely. Using SMB access as user "guest" is the path of least resistance since Tim's taken care of things behind the scenes. However, if you insist on using sftp there is a way...

You don't say what host OS you're working with. From my Linux laptop, this works once I installed the deb package openssh-sftp-server (it's installed by default on my Pi400 running Raspberry Pi OS):

assuming xxx is my moOde-player username and yyy is my moOde-player hostname

Code:

sftp -s "sudo /usr/lib/openssh/sftp-server" xxx@yyy.local
yyy.local's password:
Connected to yyy.local.
sftp>

Where my entry of the moOde user's password is blanked by sftp.

At this point I'm in user xxx's home directory with root privileges. I can navigate by the usual Linux commands to my SSD which is mounted in a m.2-to-USB enclosure and has the name Data.

Code:

cd /media/Data

At this point I can use the usual sftp commands, notably 'put' to transfer a file from my local host to my moOde player and have it saved with root:root ownership.

Regards,
Kent

[Skip Pack]

I have fought this for several years, and the one confirmed issue I hit when using two usb ssd drives plugged into my RPi4B was marginal power. One unit would work fine, the second would mount so you could see and traverse the file system from Windows using putty.exe, but it would not scan and add the audio files to the library (mpd database). This issue interacts with another issue that is most likely the one you are facing.

In order to avoid the power issue (insufficient available current), I switched to an external spinning drive, externally powered naturally, and that fixed that. I'm fairly sure a powered usb3 hub would work with the ssd drives i was using.

Intermixed with this I hit the Error 3 issue. No more traditional transfer method would reliably work for me to transfer newly acquired files to my MoOde library. There is an issue where all the standard Windows filesystem types do not contain a full set of included permissions as are normal in linux/unix filesystems. That triggers the Error 3. I tried regular ftp, sftp, and my standby WinSCP. All hit the error. Folks here have tried to help and we have never gotten the solution. Setting System>File Sharing>SMB (Samba) to 'On', and then accessing the disk via Windows Explorer under network drives give access to view and transfer files quickly and cleanly. Once this worked, I stopped chasing the 'ftp' variant solutions.

Everything works for me with the workarounds, though I remain curious why the permissions issue remains, particularly because only a minority of users seem to hit it.

Skip

[Skip Pack]

Almost contemporary posts. I agree with Kent's experience -- those have worked for me. But I would then update the library and Error 3 messages would start. There seems to be some minor, all but invisible conflict affecting the files as transferred.

[Skip Pack]

I hadn't spotted Tim's post before Kent's. That rings true to me. I'll test it myself after I update to the new version, I'm about 6 weeks behind.

[Skip Pack]

I spent some time after updating in order to duplicate as closely as I could the failed experiences with this issues, and the .conf file update worked perfectly. I'm very happy to leave that nagging question behing. Thanks Tim.

Skip

[Tim Curtis]

I spent some time after updating in order to duplicate as closely as I could the failed experiences with this issues, and the .conf file update worked perfectly. I'm very happy to leave that nagging question behing. Thanks Tim.

Skip

Did you also try turning on SMB file sharing and copying files via the client OS file manager?

[Skip Pack]

Yes, That still works fine after the change to to udisks-glue.comf, as it was with the '2022' settings.