3 hours ago
thanks. temporary fix of enabling write access to the drive got things running, if others are reading this.
reposting my github comments here though because I think there's a couple of larger issues implied by this bug:
reposting my github comments here though because I think there's a couple of larger issues implied by this bug:
Quote:just as another couple of datapoints, I was able to get jellyfin running by adjusting the umask in fstab to temporarily allow the jellyfin user to write to the drive - but even though this updating of m3u files is harmless and well-intentioned, I still think it's a highly problematic stance to take for a project to quietly modify files on a mediaserver without first asking permission from (or even notifying!!) the owner. sketchy behavior, guys.
secondly, the server was not able to come up without further help, because the migration process was referencing missing/inaccessible M3U files on a drive that I had removed last week from the mediaserver. I had removed all mention of that drive from the various libraries, but apparently the "playlists" library/database still had entries for those M3Us.
honestly I don't ever use M3Us and I don't use the 'playlists' library feature, but I have neither come across anything in the settings to configure it nor disable it. at the very least it would seem that whatever database playlists are in is not being updated by nightly library scans.