All below root is "Not Found"
Closed this issue · 21 comments
running this:
docker run -d -p 631:631 -v /var/run/dbus:/var/run/dbus --name cupsd olbat/cupsd
Website root is available but no settings or jobs page.
e.g. /admin, /jobs, /printers turns up "Not Found"
docker info
Containers: 38
Running: 31
Paused: 0
Stopped: 7
Images: 59
Server Version: 17.05.0-ce
Storage Driver: aufs
Root Dir: /var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 687
Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host macvlan null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 9048e5e50717ea4497b757314bad98ea3763c145
runc version: 9c2d8d184e5da67c95d601382adf14862e4f2228
init version: 949e6fa
Security Options:
apparmor
seccomp
Profile: default
Kernel Version: 5.4.0-113-generic
Operating System: Ubuntu 20.04.4 LTS
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 12.65GiB
Name: hattifnattarna
ID: GZ3F:PG4J:3UDB:D34L:KYF7:PDNY:RN4O:URDB:TYSO:DOCN:7SKZ:2RJT
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
WARNING: No swap limit support
I have the same issue.
I was under Openwrt Docker.
Did you find a way to solve this issue?
No, I didn't.
I returned to the printer's own print server and realised that my printer actually physically disconnects itself from power after a set timeout, so my original power sawing thought isn't applicable.
Good luck!
Getting the same issue as well. Been using this package for a while with no issues but pulled it again for the first time in a while and it's broken so probably something to do with a recent change. Shame there aren't older docker tags to fall back to.
Hey, sorry for the long overdue answer. I did not have time to work on my open-source projects a lot recently. I'm going to have a look into it and start to tag the images.
No worries we all know how it can be sometimes!
Life happens AFK and it's normally way more important. 👍
I just ran the service using the last version of the image (aa36e23091f2) and it works fine.
Which URL are you using? Are you using http://127.0.0.1:631/ ?
Hi @olbat thanks for having a look into this! I've just tested the latest image on an Ubuntu instance (18.04.5 LTS) Unfortunately it looks like the cups docker image is still not working properly. The container starts up fine and it is accessible on port :631 but only the root page works. Pages like :631/printers or :631/jobs display as "Not found"
I have the same error using tha latest version of container.
Hi @olbat same issue here, I use your image as base, then I install some printers via shell scripting.
I have a running image tagged latest, the cups version is 2.4.1, now I'm building a new one, and the cups version is 2.4.2.
In cups 2.4.2 I'm getting 404, when checked inside dockerimage I get this.
E [21/Dec/2022:15:14:59 +0000] Unable to fork /usr/lib/cups/cgi-bin/printers.cgi - Operation not permitted.
After building a custom image of cups using your Dockerfile but changing to debian:stable-slim i got my image working again, the docker version for stable-slim is 2.3.3op2.
I think the issue is relared to cups version in debian:testing-slim
Too bad :( Maybe I'll switch to debian:stable-slim until this is resolved. The reason why I used the testing image is that it was likely to have more recent drivers and therefore support for more printers.
I guess we could also investigate where this error is coming from. Maybe there is a change in the config file format or something like that?
The image is using a version of the configuration file that I mostly copy/pasted from a, now outdated, Debian version of the package. Maybe they changed something, I'm going to try updating the config file.
I made an attempt to fix the issue: #87 . Can you try the new image once it'll be available? (or rebuild the image with the new config file)
I had built a new one from your updated image, and I'm still getting 404.
By now I'll be running a custom image based in stable-slim, after I complete some tasks that I have pending I'll be testing some hotfix based in your original image, as you mentioned building from testing will give a early support to new drivers but in my particular case the printers I'm using are non open source drivers and 2.3.3op2 works well.
Thing is, I assume that a bunch of people might be relying on having recent drivers available in the image. Now I'm wondering, is this image broken for everyone or just with some printers. What's weird is that I can't reproduce :/
On what platform are you running Docker from? Are you all using an old version or something like that? (I saw 17.05, this is quite old)
Lets me see what I can do, I guess that I can start to build for both stable and testing and provide a different set of tags for image based on stable. Now I'd rather try to understand where the problem is coming from and try to fix it first.
I'm running docker 20.10.6 in swarm mode in my dev server, and a cluster for production with 3 machines with 20.10.17.
I spotted the issue in my dev server when trying to add support for a new device, as I said above I'll play with some settings and try to hotfix, debugging cupsd itself.
Thanks a lot for your help on this, please let me know if you find anything 👍
I recently had a bit of free time and did a bit of digging into the issue. When accessing a page that would return 404 I was getting this error in /var/log/cups/error_log:
Unable to fork /usr/lib/cups/cgi-bin/classes.cgi - Operation not permitted.
This was the same for all pages e.g admin page returning .../cgi-bin/admin.cgi - Operation not permitted.
I couldn't find much about this error online and after combing debian docs and messing around with permissions etc I didn't find a solution. I reverted to a docker image using debian:bullseye-slim and it fixed my issue so maybe its a bug in the current debian testing cups version?
As you mentioned earlier in the thread it might be worth tagging these releases with stable/testing. I would also recommend that the default image remain on a stable debian build for future security.
P.S Thanks for creating/maintaining all these dockerfiles, they are really helpful!
Thank you so much for investigating this and sorry for the late answer. I got too busy to properly maintain my open-source projects recently :( I'm going to give it a look next week 👍
Hey sorry, it took me way more time than expected to fix this. Images are now generated for both Debian stable & testing.
The tag name for the testing image is still latest or YYYY-MM-DD. The tag name for the stable image is stable or stable-YYYY-MM-DD.
Can you test it out?
No answers, I assume that the problem is fixed. Closing.