Search results

It was easily achieved! This PR takes care of both issues: https://github.com/Netatalk/netatalk/pull/1968 In fact, introducing the new "name" option for volumes was literally adding a single line of code. One additional line change to keep the default fallback behavior. I think it demonstrates...

@pl212 I figured out what caused the breakage: When stripping out the vendored iniparser library that netatalk has been using for over a decade, and linking with the system's shared iniparser library instead. Among the minute differences between the netatalk iniparser fork, and upstream...

Good catch. This is a recent breakage in bleeding edge 4.2.0dev. In recent weeks I've been hard at work protecting against race conditions, memory leaks and buffer overflows, so it's no surprise that there are a few bugs! Another breakage right now is that the home dir share doesn't show up...

This is more like it! Glad that you like the icon ASCII art. In fact it can print the AFP icon of a genuine AppleShare server too, not just netatalk. When it comes to the improvements to the afpgetstatus app, I wanted to get the functionality as close to the asip-status Perl script that is...

I wonder if you're still using Simon's fork here by mistake? For one, I renamed "mount_afp" to "mount_afpfs" in my fork (to be able to install cleanly on macOS, which has a native "mount_afp"). And secondly, I fixed the "extern" declaration of full_url last year with this commit...

Right, I think netatalk4 simply ignored the invalid options. Well, I'm biased, so I would suggest you use this version from my fork that I tagged yesterday! https://github.com/rdmark/afpfs-ng/releases/tag/0.9.0 Amongst other improvements and bugfixes, I made command parsing work more...

@mactjaap Well done getting this far with the migration! A few comments on your afp.conf: > [Global] > ; Set the server name that appears in the Chooser > servername = MacIPRpi > mimic model = Macintosh > appletalk = yes > uam list = uams_guest.so,uams_clrtxt.so,uams_dhx.so You would want to...

You're talking about an installer for macOS, right? You can use Homebrew to get a compiled version of netatalk ready to run. Please note that we don't have an AppleTalk stack on macOS. Apple did away with it in 2009. Linux and NetBSD are your options for AppleTalk goodness right now.

This is more of a niche project update than usual, but I'm proud to share that as of today I've put in place structures that allow anyone to translate the Netatalk manual to other languages, and have them published on the netatalk.io website in the future. (Or be packaged by distros that package...

A quick tally on the Netatalk v4 adoption in downstream distribution channels: The OSes and 3rd party repos that now distribute a version of Netatalk 4 are... Arch Linux Debian GNU/Linux Devuan GNU+Linux Fedora Homebrew Kali Linux Mageia Linux NetBSD OpenBSD OpenWrt PureOS Raspberry Pi OS...

What you can do is to mount the shared netatalk volume on any macOS or OSX machine, extract whatever data you want from dmg files and copy them onto the shared volume from where the 68k Macs can access them. You can accomplish this with something like the TashTalk, which is created by a...

FWIW, a modern Linux or NetBSD machine running netatalk 4.x is arguably a better and more reliable bridge machine for old Macs, than an old Mac with OS9. (And yes, as a netatalk maintainer I am biased.)

In concrete terms, I would say that most of these classic Mac OS bus errors mean that you're running slightly incompatible software for the hardware, or a combination of software that don't play well together. Try disabling as many Extensions and Control Panels as possible and see if the system...

Did you have to do any configuration in the CUPS admin interface, select the printer, and so on? Or was printing to your LaserWriter plug'n'play once you had installed the pap backend? Did you have to edit cups.conf as well? What is the exact model of LaserWriter, for our reference? I'm...

It is kind of a miraculous feeling when hardware from such different eras interoperate, isn't it! So I found the source of the CUPS pap backend configuration, namely this article on the EMaculation wiki. The tarball with the backend configuration and license text are available for download...

This explains it. I’ll add the info to our wiki page.

Hmm, all of this shouldn't be required. If CUPS is aware of your printer, you should only have to put cupsautoadd:op=root: in papd.conf and that's it. See this guide that I wrote some time ago: https://netatalk.io/docs/Print-Server

You are correct, both CUPS and papd need to be configured. For papd, the papd.conf file must have the cupsautoadd directive with f.e. root owner. A while ago I wrote this guide on configuration and troubleshooting of papd and CUPS: https://netatalk.io/docs/Print-Server

I'm not familiar with a /usr/lib/cups/backend/pap file. Is it a plain text or binary file? This is not something that Netatalk creates or touches directly.

@mactjaap Regarding Fizzbin's problem, do you remember if you had all CUPS dependencies installed when you built netatalk? It is possible to build papd without CUPS, at which time you get a traditional BSD line printer daemon interface instead.