jon's questions

I have Samba running on a plug computer running Debian Squeeze which I'm trying to configure to act as a web-based file server.

The machine runs Lighttpd for the web server, and Samba for the file sharing. The user is able to use Samba to copy files from their local machine onto the plug computer using Samba, and then view them through the web browser (script I wrote).

Lighttpd runs as www-data, Samba runs as root and the user authenticates with Samba through a user account called admin.

The problem is that I'm having permissions difficulties when a user copies files from their machine over Samba. Let's take an example with a file called foo.pdf:-

Example

foo.pdf is stored on a separate NAS drive on the LAN, which the user copies over to their local machine running OS X. The permissions right now are as follows:-

mac:Desktop jon$ ls -l | grep foo.pdf
-rwx------    1 jon  NETWORK\Domain Users     3516266 10 May 10:54 foo.pdf

Everything is fine, because the user has full rights to rwx the file, even though no-one else does -- which isn't a problem. But now, the user decides they want to copy foo.pdf from their local machine onto the plug computer -- and things start to go wrong!

After using Samba to copy the file over, the permissions are now as follows:-

root@plug:/home/admin/content# ls -l | grep foo.pdf
-rwx------ 1 admin    admin    3516266 May 10 09:54 foo.pdf

The problem is that now only admin has the rights to rwx the file. No other users have any rights at all. This means that www-data (which is the web server) has no rights to this file. The result is a 403 - Forbidden if I try to open foo.pdf through a web browser.

My *nix knowledge is fairly limited, but I reckon that what needs to happen to fix this is that Samba needs to relax these permissions when copying over files to allow other users to read the file.

Reading similar questions on SF and other sites indicates that a potential solution may lie in the create mode/mask and force create mode/mask -- however it's not clear whether this only applies to new files, or also to copied files -- because it's not working for me!

As a test, I used those options to force 0777 (obviously unsafe for a production environment, but just wanted to test) and found that it made no change whatsoever to the file permissions of copied over files.

My smb.conf is as follows:-

[global]
        workgroup = WORKGROUP
        server string = %h server
        dns proxy = no
        log file = /var/log/samba/log.%m
        log level = 4
        max log size = 1000
        syslog = 0
        panic action = /usr/share/samba/panic-action %d
        encrypt passwords = true
        passdb backend = tdbsam
        obey pam restrictions = yes
        unix password sync = yes
        passwd program = /usr/bin/passwd %u
        passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword$
        pam password change = yes
        create mask = 0777
        force create mode = 0777
        directory mask = 0777
        force directory mode = 0777

This doesn't seem to change anything at all, as files still have the -rwx------ 1 admin admin permissions after being copied over.

...any ideas?

I have a machine running Ubuntu on which I've installed Apache (v2).

What I'm trying to do is enable ZeroConf so that the Apache server will broadcast itself over the network and then will be able to be picked up using Bonjour on OS X systems.

It seems that Apache unfortunately has no support for ZeroConf out-of-the-box so some additional module will be needed.

There are a number of different libraries out there compatible with various versions of Apache and operating systems but mostly fairly out-of-date (mod_zeroconf, mod_rendezvous, mod_bonjour, libapache2-mod-dnssd, amongst others)

Has anyone had any experience with these different libraries and can they recommend a fairly current one that is compatible with Apache2 on Ubuntu?

I have the following very peculiar issue with using Avahi on the DreamPlug (which is a plug computer running Ubuntu Jaunty).

After spending days on this, I think I've managed to narrow down the issue.

The DreamPlug acts as the WiFi access point, and has the hostname plug and IP address 192.168.1.1 (which is set in both /etc/hosts and /etc/hostname) and runs lighttpd.

Now my Mac works straight away with accessing http://plug.local in Chrome, however if I try and load http://plug.local on the iPad, it doesn't work. That is, it doesn't work until I load the page on the desktop.

For some reason, the iPads are never able to resolve the hostname, until the hostname is first resolved on the Mac... which is weird because there is no connection between the iPads and the Mac other than the fact that they are connected to the same access point (the DreamPlug).

So just to clarify again: Safari on the iPad will hang (until it reports that browsing failed) when accessing http://plug.local unless I access http://plug.local on the Mac, run ping plug.local, do ssh [email protected] or basically do anything else that resolves the hostname, at which point the iPad instantly resolves the hostname and it starts working properly.

If my understanding is correct, when the iPads connect they broadcast a resolution request for plug.local. For whatever reason, this request is ignored by the DreamPlug (or it never gets received). However, the Mac does manage to broadcast its request. It broadcasts a resolution request and the DreamPlug brodcasts back the result plug.local -> 192.168.1.1. The iPads then receive this result (which was really destined for the Mac) and are then able to resolve successfully.

I'd be happy to supply my avahi-daemon.conf or other config files on request.

Update: I've now managed to use Wireshark and found that the iPads do indeed broadcast a request to the network.

I've captured both a packet that DID result in a response from Avahi, as well as one that did NOT.

They both appear completely identical, the only difference is that the one that failed specified an additional RR of type OPT... I have no idea what an OPT record is. Could it be that Avahi doesn't like DNS queries with OPT RRs attached for some reason?

Here are two screenshots taken from Wireshark. The first one shows a "good" mDNS request which is sent from the desktop computer (in this case, the device is called runway.local). This query works fine and the server (at 192.168.1.1) responds straight away:

Here is an example of the response that is returned from runway.local:

Meanwhile, here is a second DNS query which has been sent from the iPad for the same hostname, runway.local. In this case, the request seems to be simply ignored (in any event, no response is ever received for this DNS query):

Trying to track down what it is in the iPad request that causes the issue, it appears that the two packets are almost identical, the only difference between mDNS queries sent from the desktop (running OS X) and the iPad, is that the iPad appends an OPT resource record to the bottom of the DNS request.

The question is: what is the significance of the resource record -- and is it this -- or is it something else -- that is responsible for this DNS request being ignored by Avahi.

UPDATE This could be the breakthrough I've been looking for:

I've been running avahi-daemon with --debug flag and I've noticed a lot of "Invalid query packet." messages. This led me to this page: http://avahi.org/ticket/284 which seems that this is a known issue (albeit one that's supposed to be resolved).

Specifically:

A tcpdump makes me believe that this is due to Mac OS 10.6 using RFC2671 to add information in the additional data section of DNS queries. Specifically, it is supplying the 'UDP payload size' (in my case, 1440) as hint for the max size of response packets. [...] Avahi considers queries with non-empty additional data sections invalid, where it checks that AVAHI_DNS_FIELD_ARCOUNT != 0 just before generating the Invalid query packet message.