Open cbrenberg opened 3 months ago
Is it actually the mympd
user which requires access, and not the mpd
user? I know that myMPD has some additional features on top of MPD, which do allow filesystem access, but I remember also that I discussed this exactly with its author, and that access to /var/lib/mympd
was all that is needed. Or we were talking about write access only, not 100% sure. The mpd
user should be member of dietpi
group already.
However, as you also mentioned to set the Samba mount point as MPD directory and auto-detect it via MPD socket, it does not make much sense the myMPD requires access directly. Please verify this works as well:
chmod -R 'o-rwx' /path/to/mount
useradd -rMN -g dietpi -d /var/lib/mympd -s /usr/sbin/nologin mympd
Thanks for the reply. chmod doesn't throw any errors, but the change does not take effect when run against a samba mount, which is what led me to modifying the permissions in my fstab file to fix it.
This discussion in the myMPD repo describes the same exact symptoms I was experiencing in the myMPD UI, which makes me believe that the mympd user requires read access to the MPD music directory. The mpd user already had access via membership in the dietpi group: https://github.com/jcorporation/myMPD/issues/1303#issuecomment-2143989726
Seems you are right. Still not sure how to solve best if we want to keep the dynamic user. Maybe it can be still given dietpi
as supplementary or primary group. I'll test.
I would prefer this, as documented in the myMPD documentation:
mkdir /etc/systemd/system/mympd.service.d
echo -e '[Service]\nSupplementaryGroups=dietpi' > /etc/systemd/system/mympd.service.d/music-group.conf
Using a smb mount as music directory has some disadvantages. For example I noticed that filenames with a colon in the name are not supported, a NFS mount is preferable in my opinion.
Creating a bug report/issue
Required Information
Additional Information (if applicable)
Steps to reproduce
On a system running MPD with a music directory located on a Samba share that was mounted using dietpi_drive-manager:
Expected behaviour
Actual behaviour
Extra details
I was able to resolve this on my system by editing the permissions for my music directory mount in 'etc/fstab' from 0770 to 0774.
Other possible solutions would be to assign mympd's systemd user to the 'dietpi' group when it's created or to add additional options within dietpi_drive-manager to override the default user/group/permissions that it writes to /etc/fstab