The following error occurs when… I wish I knew that.
[Req#263ef/Transcode/ackgr7hd99b1in5tp57aicxu/5b1aa7f1-b329-41a7-8a06-3e50dc2ecabb] [eac3_eae @ 0x7fc6e84f5080] EAE watchfolder is not writable: /tmp/pms-31549552-62ec-40b5-9322-bc6760a29f6a/EasyAudioEncoder/Convert to WAV (to 8ch or less)/ackgr7hd99b1in5tp57aicxu_2443-0-test.tmp
But basically it is saying that something in “/tmp” is not writable. That’s funny because it was all the time before. I am running plex inside docker and “/tmp” in the container is “/dev/shm” on linux Debian. What I could observe is that there was this folder “pms-31549552-62ec-40b5-9322-bc6760a29f6a” and folder “Transcode” inside. But after some time or after a trigger that I don’t know yet, the “pms-31549552-62ec-40b5-9322-bc6760a29f6a” directory was deleted but “Transcode” still remains. And plex then tries to access something that simply does not exist anymore.
Does anybody know what is happening there? If I now restart the docker container. Plex will create a folder like the one before besides “Transcode” in “/tmp” again. But it does take only some time, and then the folder gets deleted again. And the error occurs again.
Update: maybe it is the whole content of “/tmp” that gets deleted, but Plex is only capable of recreating “Transcode” folder. Because now as I randomly checked again and did not wait for the error to occur (when playing a video file), I saw that “/tmp” was completely empty. But after trying to play a movie “Transcode” got created again bot not the other missing folder. So something is clearing transcode folder “/tmp” aka “/dev/shm” completely. But Plex is not able to create all the necessary folders/files after that. Only a restart triggers Plex to create everything that’s needed, after the deletion of the transcode folder content has happened.
Post your docker compose file.
pretty basic, nothing fancy: left out volumes of my media
plex:
image: linuxserver/plex
container_name: plex
network_mode: host
environment:
- PUID=1000
- PGID=1000
- VERSION=docker
- TZ=Europe/Berlin
volumes:
- ./volumes/plex:/config
- /dev/shm:/tmp
- /mnt....
.
.
.
restart: unless-stopped
Is there a reason you are not bind mounting the volume for/config?
I don’t understand the question. It is literally there
Nevermind, I just figured this out on my own.
This is ridiculous.
An open ssh connection (to the host machine of the running plex docker container) which was not terminated clean by exiting the session or closing the terminal is the cause for this.
I can replicate this issue/the error when establishing an ssh connection and then just restarting the laptop without properly closing the ssh connection. Whatever happens then is causing the other end of the forcefully closed ssh connection to delete all the content inside of “/dev/shm”.
I don’t know if I want to look into that even further. This is, like I said, a consistent behaviour and I can replicate this.
For now I guess:
Just don’t use “/dev/shm” for ram transcoding. Instead mount your own tmpfs ram folder. Because I never ran into problems before with that. Did it with a separate folder in the past. I just changed recently to using “/dev/shm” as I switched from one host to another host machine because it got recommended in so many threads.
My recommendation now: Don’t you dare using the systems native “/dev/shm” tmpfs folder for Plex ram transcoding. Mount your own one for Plex.
This is not a bind mount, it’s internal to the container.
volumes:
- ./volumes/plex:/config
Bind mounts | Docker Docs to answer your question.
I don’t know …
a) why I should prefer “bind mounts” (what you are referring to) over “volumes” (what I am using) and
b) what this has to do with the error I described