Geo coordinates from t-shirts.

53°37'15.6"N 9°57'26.5"E

TOM TAILOR 53°37'15.6"N TOM TAILOR 9°57'26.5"E
CASUAL 1962 CLASSICS

This is the "Tom Tailor Outlet Store" in Hamburg Niendorf, 53.621000, 9.957361.

Sometimes I need to remove tags HTML page that I fetched with curl on the command line. It's pretty easy to do with html2text:

$ curl -s example.org | html2text

html2text reflows the text and changes line breaks. When using sed the line breaks are kept:

$ curl -s example.org | sed 's|<[^>]*>||g'

(But CSS style tag content is not removed)

While setting up Munin on my new server I got an error when accessing its CGI HTML and graph endpoints:

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

With Debian's own /etc/apache2/conf-available/munin.conf and mod_fcgi, the Apache log files showed:

[fcgid:warn] [pid 604137:tid 604188] (104)Connection reset by peer: [client 2a00::1:37614] mod_fcgid: error reading data from FastCGI server
[core:error] [pid 604137:tid 604188] [client 2a00::1:37614] End of script output before headers: munin-cgi-html
  

When switching to proxy access as described on the Debian Munin wiki page, I got this:

[proxy:error] [pid 615310:tid 615315] (111)Connection refused: AH02454: FCGI: attempt to connect to Unix domain socket /run/munin/fcgi-html.sock (127.0.0.1:8000) failed
[proxy_fcgi:error] [pid 615310:tid 615315] [client 2a00::1:47122] AH01079: failed to make connection to backend: 127.0.0.1
  

In the end the problem was that both munin-graph and munin-html services failed to start:

$ systemctl status munin-graph
× munin-graph.service - Munin FastCGI Graph
     Loaded: loaded (/etc/systemd/system/munin-graph.service; static)
     Active: failed (Result: exit-code) since Sun 2025-12-28 13:51:00 CET; 5h 50min ago
   Duration: 123ms
 Invocation: 6d15c12984364418a0b8b996dc5fc072
TriggeredBy: ● munin-graph.socket
    Process: 588072 ExecStart=/usr/lib/munin/cgi/munin-cgi-graph (code=exited, status=13)
   Main PID: 588072 (code=exited, status=13)
   Mem peak: 17.5M
        CPU: 103ms

Dez 28 13:51:00 ahso5 systemd[1]: Started munin-graph.service - Munin FastCGI Graph.
Dez 28 13:51:00 ahso5 munin-cgi-graph[588072]: [Sun Dec 28 13:51:00 2025] munin-cgi-graph: Can't open /var/log/munin/munin-cgi-graph.log (Permission denied) at /usr/share/perl5>
Dez 28 13:51:00 ahso5 munin-cgi-graph[588072]: Unable to flush stdout: Der Socket ist nicht verbunden
Dez 28 13:51:00 ahso5 systemd[1]: munin-graph.service: Main process exited, code=exited, status=13/n/a
Dez 28 13:51:00 ahso5 systemd[1]: munin-graph.service: Failed with result 'exit-code'.
  

The log file was owned by www-data, although the systemd services are running as munin user. Changing the ownership solved the problem:

$ chown munin /var/log/munin/munin-cgi-*
$ systemctl restart munin-graph
$ systemctl restart munin-html
  

Beim Umzug zu unserem neuen Server musste ich irgendwann auch die "Glue Records" im DNS anpassen, was sich in Kombination mit IPv6 als schwierig herausstellte.

Leim?

Um die IP-Adresse zu einem Domainnamen wie cweiske.de bekommen zu können, muss ein Client wenigstens die IP-Adressen der Root-DNS-Server haben. Als Beispiel nehmen wir den 2. Root-Server b.root-servers.net mit der IP 199.9.14.201.

Jetzt kann man diese nach dem DNS-Server für diese Domain fragen - und sie werden uns mitteilen, daß sie die Antwort nicht kennen, aber wissen, wen wir fragen können: Die DNS-Server der DENIC, die die .de-Zone verwalten:

$ dig @199.9.14.201 cweiske.de NS
;; AUTHORITY SECTION:
de.			172800	IN	NS	a.nic.de.

;; ADDITIONAL SECTION:
a.nic.de.		172800	IN	A	194.0.0.53
a.nic.de.		172800	IN	AAAA	2001:678:2::53

Nun wissen wir, daß wir a.nic.de auf der IP 194.0.0.53 fragen sollen, wer denn der zuständige Nameserver für cweiske.de ist:

$ dig @194.0.0.53 cweiske.de NS
;; AUTHORITY SECTION:
cweiske.de.		86400	IN	NS	ns1.cweiske.de.

Zuständig ist also der Nameserver ns1.cweiske.de, der uns die IP für cweiske.de auflösen kann!

Das Problem ist nur: Was ist die IP von ns1.cweiske.de? Wenn wir den ganzen Prozess wieder starten wird rauskommen, daß der Server ns1.cweiske.de für ns1.cweiske.de zuständig ist...

Um aus dieser Endlosschleife herauszukommen, gibt es im DNS die Glue-Records. Zusätzlich zum Nameserver wird bei der DENIC nämlich auch die IP des Nameservers vorgehalten und bei Anfragen mit ausgeliefert:

$ dig @194.0.0.53 cweiske.de NS
;; AUTHORITY SECTION:
cweiske.de.		86400	IN	NS	ns1.cweiske.de.

;; ADDITIONAL SECTION:
ns1.cweiske.de.		86400	IN	A	83.169.45.222
ns1.cweiske.de.		86400	IN	AAAA	2a01:488:66:1000:53a9:2dde:0:1

Auch die DNS-Rootserver halten diese Leimdatensätze vor, denn sonst wären wir schon mit der Auflösung von a.nic.de gescheitert.

Hosteurope

Im Domain-Interface des KIS war nicht wirklich klar, wie man sowohl IPv4- als auch IPv6-Adressen angeben kann.

Ich habe es auf die verschiedensten Arten gemacht, nur um dann von der DENIC je eine der folgenden Fehlermeldungen zu bekommen:

Failed to Modify Domain Nameservers: The domain DNS check has failed.

Invalid Parameter: Nameservers are not unique.

Der Support gab mir dann den entscheidenden Hinweis: IPv4- und IPv6-Adresse müssen hintereinander, mit Leerzeichen getrennt, ins Feld "Primary DNS Netaddress" eingetragen werden:

Nameserver	Primary DNS Hostname*	ns1.cweiske.de
	Primary DNS Netaddress	83.169.45.222 2a01:488:66:1000:53a9:2dde:0:1
	Secondary DNS Hostname*	AUTO

Damit akzeptierte die DENIC den Domain-Änderungsauftrag und Dr. Bopp konnte Erfolg vermelden.

2025-12: IPv6-Probleme

2025 gibt es einen Bug im Domainsystem von Hosteurope. Wenn man den Nameserver umzieht und dabei die Domain ändert (ns4.cweiske.de -> ns5.cweiske.de), bisher nur IPv4 eingetragen hatte und jetzt eine neue IPv4-Adresse und noch eine IPv6 eintragen will, kommt ein Fehler:

QUEUED: [example.org] - Unser Nameserver nicht in Ihrer Primary-NS-Konfiguration

Der im Auftrag angegebene Primary-Nameserver liefert keine (den Angaben aus dem Update-Auftrag entsprechenden) NS-Records für die betreffende Domain aus. Bitte legen Sie auf Ihrem Primary Nameserver eine DNS-Zone für die betreffende Domain an, mit folgenden NS-Records:

ns5.cweiske.de
pdns02.domaincontrol.com

Das passiert, obwohl der Nameserver korrekt konfiguriert ist. Die Lösung ist es, zuerst nur Aufträge für die IPv4-Adresse zu machen, und - wenn die durch sind - neue Update-Aufträge für IPv4+IPv6.

Für eine CallYa-Kartenübernahme bei Vodafone musste ich die SIM-Kartennummer einer SIM-Karte auslesen.

Entgegen aller Anleitungen im Internet war es unmöglich, die ICCID auf einem Samsung Galaxy A35 5G (Modellname SM-A356B/DS) mit One UI 8.0 (Android 16) auszulesen.

In Einstellungen > Telefoninfo > Statusinformationen war die ICCID nicht zu sehen, auch nicht in SIM-Kartenstatus oder IMEI-Informationen. Unter Einstellungen > Verbindungen > SIM-Manager war die Seriennummer auch nicht.

Der Wahlcode *#06# zeigte nur die IMEI, EID und Seriennummer des Telefons - nicht aber die der SIM-Karten.

Die App Sim Serial Number ( ICCID) (it.ale32thebest.simserialnumber) war als mit Android 16 kompatibel markiert, zeigte nach dem Start aber an, daß sie nicht mehr mit Android 13 oder höher funktioniert. Natürlich war das im Google Play Store nicht angegeben; man musste erst die App starten und die In-App-Werbung ansehen, bis man diese Information bekam.

Zum Schluß steckte ich die SIM-Karte in mein Fairphone 4 mit LineageOS 22 (Android 15), und konnte die ICCID dort unter Einstellungen > Über das Telefon > SIM-Status (SIM-Steckplatz 1) ablesen.

Screenshots One UI 8

Ende des letzen Monats fror das Fernsehbild ein. Ich startete die Dreambox 7080HD neu, nur um im Display folgende Meldung zu sehen:

loading setup...
rescue mode
  

Ich konnte dann per Browser auf den Rettungsmodus zugreifen:

DM7080 Rescue Loader #103

Device information
Online recovery
Firmware upload
Settings Backup
Settings Restore

If you see this, your Dreambox didn't boot its operating system. Unless you interrupted the boot process manually, this usually means that there's no valid operating system installed.

Don't worry, it's not a problem. You can just run our recovery mechanism, which tries to fetch and install known-good firmware from dreamboxupdate.com, or upload your own firmware file.

It's possible to create and download a backup copy of your data.

You may as well just reboot your box and come back later, maybe after a short visit in our online support board, where you can ask for help if required.

Das Herunterladen des Einstellungs-Backups funktionierte nicht; die Dreambox hängte sich auf.

Die "Online recovery" blieb beim Schreiben auf den Flash-Speicher auch hängen:

[*] Downloading 'http://dreamboxupdate.com/download/recovery/dm7080/release/recovery.sig'
[*] Downloading 'http://dreamboxupdate.com/download/recovery/dm7080/release/recovery'
[*] Verifying signature of 'recovery'
gpgv: Signature made Thu Sep 14 15:34:18 2017 UTC using RSA key ID D6CF56E7
gpgv: Good signature from "Dreambox DM7080 Recovery <recovery@dm7080.com>"
[*] Running './recovery'
[*] Options '-v'
Fatal: Target device '/dev/mmcblk0p1' is not writable
Fatal: Failed to execute './recovery'
  

Der "Firmware upload" ebenfalls:

[*] Creating partition table

Das wars. Der nicht austauschbare interne Flash-Speicher ist defekt, der Satellitenreceiver startet nicht mehr - 11 Jahre nach der Inbetriebnahme.

Dreambox?

Seit den frühen 2000er Jahre war Dreambox für mich der Inbegriff von hochwertigen, hackbaren Satelliten-TV-empfängern. Meine erste Dreambox war 2008 die 7025+, dann kam aus technischen Gründen die 7080HD, und vor einem Jahr noch eine 525 für das Gästezimmer.

Im Juli 2023 ging das offizielle Forum und der Update-Server dreamboxupdate.com offline. Die Dream Property GmbH wurde am 13.12.2023 aufgelöst. Im November 2023 war die Website wieder da.

Aktuell steht auf der Supportseite, daß die Satco Europe GmbH Support übernimmt - von denen habe ich aber auf die Frage, ob meine defekte 7080HD repariert werden kann, keine Antwort bekommen.

High-End-Receiver

Der letzte Satellitenreceiver Dreambox Two kam Mitte 2020 auf den Markt - wie die Dreambox One (2019) kann er sowohl das Enigma2-Betriebssystem und auch Android booten.

Das letzte klassische Gerät war die DM920 von 2017.

Die Two ist genauso wie die DM920 komplett ausverkauft und nirgendwo mehr neu zu bekommen. Die One gibt es noch - aber nur mit Dual-Tuner. Lediglich die DM900 von 2016 hat genug Tuner für meinen Bedarf und ist noch neu kaufbar :(

Es sieht so aus, als ist die Zeit der Premium-Satellitenempfänger vorbei. Die VU+ DUO 4K SE des Konkurrenten VU wurde auch schon Ende 2020 veröffentlicht - es kommen keine neuen Geräte mehr heraus.

Vermutlich ist es die Umstellung auf Streaming, die den Markt kaputtgemacht hat.

Seit März 2025 gibt es die Dreambox Play, die allerdings nur ein AndroidTV-Gerät mit Dreambox-Namen ist. Kein Fernsehtuner mehr, nur noch Streaming. Hier wurde der gute Name gekauft, um billige Hardware an den Mann zu bringen.

Ersatzgerät: DM900

Die mir einzige verbliebene Option war der Kauf einer neuen DM900 mit DVB-S2X FBC MultiStream Tuner (8 gleichzeitige Fernsehprogramme!) für 328€, auch wenn ich lieber die 920 gehabt hätte.

Problem: Festplatte

Ein Problem war, daß ich den Inhalt 3.5" 3TB-Festplatte auch in den neuen Dreambox unterbekommen wollte, die aber nur 2.5"-Festplatten kann. Ich kaufte also eine 2.5" 5TB-Festplatte um dann zu lernen, daß es die 2.5"-Platten in unterschiedlichen Höhen gibt - und die DM900 nur 9mm kann. Meine neue Platte war 15mm :(

Erst wollte ich die Platte in die Mitte des Deckels schrauben und mit einem SATA-Verlängerungskabel anschließen. Bei genauerem Hinsehen stellte ich aber fest, daß der Prozessor auf der Hauptplatine direkt darunter angebracht ist und ziemlich warm wird. Die Platte direkt darüber hätte zu einem Wärmestau geführt, was die Lebensdauer verkürzt hätte.

Zum Schluß lieh ich mir deshalb einen Dremel aus und schnitt ein Loch in den Deckel. Sieht ganz ok aus:

Problem: Unstable-Feed

Die neueste stabile Firmware für die DM900 ist von 2019, zu finden auf dreamboxupdate.com.

Dort gibt es auch den unstable-Feed, der 2021 aktualisiert wurde. Der heißt nicht umsonst unstable, aber es ist das letzte, was von Dream zur Verfügung gestellt wurde.

Nach dem Ersetzen der apt-Feed-URL durch unstable kam folgender Fehler:

root@dm900:~# apt upgrade
[...]
Setting up kernel-image (3.14-r0.175) ...
Fatal: Unsupported machine!
dpkg: error processing package kernel-image (--configure):
 subprocess installed post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of kernel-base:
 kernel-base depends on kernel-image; however:
 Package kernel-image is not configured yet.
  

Die Lösung fand ich in im newnigma2-Forum im Thread [gelöst] Loader update geht nicht?:

Es gab vor etwa 2 Jahren ein fehlerhaftes flash-scripts paket am feed, das nur flash-scripte für die one/two enthielt - daher der Fehler "Unsupported machine!"

Am Newnigma2 und auch am Merlin feed wurde das mittlerweise gefixt - d.h. man hat die korrekten flash-scripts installiert, wenn das Image am aktuellen Stand ist.

Die flash-scripts_1.1+git2+236c3921a1-r0.0_armhf.deb von http://feed.newnigma2.to/daily/oe2.5/deb/dm900/ konnte ich runterladen und installieren, allerdings wurden sie mit jedem apt upgrade wieder mit der kaputten Version überschrieben:

root@dm900:~# apt upgrade
[...]
The following packages will be upgraded:
  flash-scripts
[...]
Preparing to unpack .../flash-scripts_1.1+git12+530b1eb807-r0.0_armhf.deb ...
Unpacking flash-scripts (1.1+git12+530b1eb807-r0.0) over (1.1+git2+236c3921a1-r0.0) ...
Setting up flash-scripts (1.1+git12+530b1eb807-r0.0) ...
Setting up kernel-image (3.14-r0.175) ...
Fatal: Unsupported machine!
dpkg: error processing package kernel-image (--configure):
 subprocess installed post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of kernel-base:
 kernel-base depends on kernel-image; however:
  Package kernel-image is not configured yet.
  

Die Lösung ist es, die alte Version zu pinnen. Damit bekommt die neue Version eine höhere Priorität und wird nicht mehr mit der kaputten aus dem unstable-Feed überschrieben.

root@dm900:~# cat /etc/apt/preferences.d/broken-flash-scripts
Package: flash-scripts
Pin: version 1.1+git2+236c3921a1-r0.0
Pin-Priority: 1001
  

When trying to mount a NFS share on my Dreambox satellite receiver, I got an error:

root@dreambox:~# mount /media/server/
mount.nfs: access denied by server while mounting 192.168.3.3:/data/dreambox/media
  

I was pretty sure that the client's IP was allowed on the server:

root@myserver:~# exportfs -v
/data/dreambox/media  dreambox(sync,[...])
  

Debugging the server

At first NFS debugging must be enabled, then the NFS server restarted:

root@myserver:~# rpcdebug -m nfsd -s all
nfsd       sock fh export svc proc fileop auth repcache xdr lockd

root@myserver:~# systemctl restart nfs-mountd.service
root@myserver:~# journalctl -ef
kernel: NFSD: Using nfsdcld client tracking operations.
kernel: NFSD: starting 90-second grace period (net f0000000)
systemd[1]: Finished nfs-server.service - NFS server and services.
rpc.mountd[2116307]: connect from 192.168.3.42 denied: request from unauthorized host
  

This did not help me at the time. I disabled NFS debugging again:

root@myserver:~# rpcdebug -m nfsd -c all
root@myserver:~# systemctl restart nfs-mountd.service
  

Debugging the client

The mount program has a --verbose option:

root@dreambox:~# mount -vvv /media/server/
mount.nfs: timeout set for Sun Dec  7 11:35:02 2025
mount.nfs: trying text-based options 'udp,retrans=1,tcp,wsize=8192,retry=0,nolock,timeo=2,rsize=8192,soft,nofail,vers=4.2,addr=192.168.3.3,clientaddr=192.168.3.42'
mount.nfs: mount(2): Invalid argument

mount.nfs: trying text-based options 'udp,retrans=1,tcp,wsize=8192,retry=0,nolock,timeo=2,rsize=8192,soft,nofail,vers=4.1,addr=192.168.3.3,clientaddr=192.168.3.42'
mount.nfs: mount(2): Invalid argument

mount.nfs: trying text-based options 'udp,retrans=1,tcp,wsize=8192,retry=0,nolock,timeo=2,rsize=8192,soft,nofail,vers=4.0,addr=192.168.3.3,clientaddr=192.168.3.42'
mount.nfs: mount(2): Invalid argument

mount.nfs: trying text-based options 'udp,retrans=1,tcp,wsize=8192,retry=0,nolock,timeo=2,rsize=8192,soft,nofail,addr=192.168.3.3'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 192.168.3.3 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=6
mount.nfs: trying 192.168.3.3 prog 100005 vers 3 prot TCP port 33963
mount.nfs: portmap query failed: RPC: Authentication error
mount.nfs: access denied by server while mounting 192.168.3.3:/data/dreambox/media
  

The client tries to use NFS v4.2 first, gets an error and falls back to lower NFS versions until it reaches NFS v3. NFSv3 then gets an "access denied".

I then tried listing the available mounts:

root@dreambox:~# showmount -e myserver
rpc mount export: RPC: Authentication error; why = Failed (unspecified error)
  

This was when I remembered that I disabled the public listing of NFS shares! mountd is not available on the server, and is not needed for NFS v4.

Why no NFSv4?

Now I only had to find out which of the options were not compatible with NFS v4. When hard-coding the NFS version to 4 in /etc/fstab I got a slightly more detailled - but still unhelpful - error message:

root@dreambox:~# mount -vvv /media/server/
mount.nfs: timeout set for Sun Dec  7 11:56:21 2025
mount.nfs: trying text-based options 'udp,retrans=1,tcp,wsize=8192,retry=0,nolock,timeo=2,rsize=8192,soft,nofail,vers=4,addr=192.168.3.3,clientaddr=192.168.3.42'
mount.nfs: mount(2): Invalid argument
mount.nfs: an incorrect mount option was specified
  

Now I converted the fstab entry into a mount arguments and removed them one by one:

root@dreambox:~# mount -vvv -o nfsvers=4,x-systemd.automount,retrans=1,noauto,wsize=8192,x-systemd.idle-timeout=60,retry=0,nolock,rw,x-systemd.device-timeout=15,timeo=2,x-systemd.mount-timeout=15,rsize=8192,soft,nofail 192.168.3.3:/data/dreambox/media /media/server
  

nofail, the last option, was the one that was not usable for NFS v4. It had been added by the enigma2 network browser.

My Dreambox DM7080HD's internal flash chip died after 11 years, and after purchasing a DM900 I wanted to copy the movies from the old 3.5" 3 TB hard disk to the new 2.5" 5 TB SATA disk installed inside the new satellite TV receiver.

I attached the disk to my rusty old SATA-to-USB-adapter (JMicron JM20337 USB to ATA/ATAPI Bridge, USB ID 152d:2338) and connected it to the dreambox. The disk was recognized, but no partitions would be found. dmesg showed that the disk size was only 700 gigabytes instead of 3 terabytes:

usb 3-2.2: USB disconnect, device number 17
usb 3-2.2: new high-speed USB device number 18 using xhci_hcd
usb 3-2.2: New USB device found, idVendor=152d, idProduct=2338, bcdDevice= 1.00
usb 3-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=5
usb 3-2.2: Product: USB to ATA/ATAPI Bridge
usb 3-2.2: Manufacturer: JMicron
usb 3-2.2: SerialNumber: 7CC48306C0E5
usb-storage 3-2.2:1.0: USB Mass Storage device detected
scsi host0: usb-storage 3-2.2:1.0
scsi 0:0:0:0: Direct-Access     WDC WD30  WD-WCC4N30LCPEU 0A80 PQ: 0 ANSI: 2 CCS
sd 0:0:0:0: Attached scsi generic sg0 type 0
sd 0:0:0:0: [sda] 1565565872 512-byte logical blocks: (802 GB/747 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 38 00 00
sd 0:0:0:0: [sda] Asking for cache data failed
sd 0:0:0:0: [sda] Assuming drive cache: write through
sd 0:0:0:0: [sda] Attached SCSI disk
  

fdisk also told me that the hard drive was smaller than I expected, but the partition on it was larger - but only 2TB instead of 3:

root@frm:~> fdisk -l /dev/sda
Disk /dev/sda: 746,52 GiB, 801569726464 bytes, 1565565872 sectors
Disk model:  WD-WCC4N30LCPEU
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot Start        End    Sectors Size Id Type
/dev/sda1           1 4294967295 4294967295   2T ee GPT
  

I unplugged the disk, attached it to my laptop and installed gdisk, a fdisk for GPT partitions:

root@frm:~> gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.10

Warning! Disk size is smaller than the main header indicates! Loading
secondary header from the last sector of the disk! You should use 'v' to
verify disk integrity, and perhaps options on the experts' menu to repair
the disk.
Caution: invalid backup GPT header, but valid main header; regenerating
backup header from main header.

Warning! One or more CRCs don't match. You should repair the disk!
Main header: OK
Backup header: ERROR
Main partition table: OK
Backup partition table: ERROR

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: damaged

****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************

Command (? for help): p
Disk /dev/sda: 1565565872 sectors, 746.5 GiB
Model:  WD-WCC4N30LCPEU
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): AFB7463D-B5C2-409F-86BB-C113231DDDB2
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 5860533134
Partitions will be aligned on 8-sector boundaries
Total free space is 3933 sectors (1.9 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048      5858436016   2.7 TiB     0700  primary
   2      5858436017      5860531215   1023.0 MiB  8200  primary

  

This was when I stopped experimenting on my laptop and searched for an explanation of the wrongly reported hard drive size. I found it in an answer by Rod Smith on Ask Ubuntu:

External USB enclosures often impose 32-bit limitations on disk sector values. 2^32 sectors, times a 512-byte sector size, means that these enclosures can handle, at most, 2 TiB disks.

Frequently, the symptom of using a disk bigger than this is that the disk size is reported as the disk's true size modulo 2 TiB -- that is, your 2.73 TiB disk is reported as 0.73 TiB.

This was the problem. The JM20337 SATA-to-USB adapter was from 2003, and just doesn't support disks larger than 2TB.

Connecting the drive to a more recent 4TB video backup harddisk adapter did work, and dmesg showed the real drive size. The partition table was broken, but I could recover it with TestDisk.

The network shares ("exports") available on a NFS server can be listed with showmount -e myserver. It will list all exported directories, even if the client is not allowed to mount all of them.

This here is a workaround. A real solution - hiding all exports that the client does not have access to, but showing the rest - does not exist to my knowledge.

With NFS v4 it is possible to limit listing the shares to select clients only: By restricting access to rpc.mountd via /etc/hosts.allow:

mountd: client1 client2

This will allow client1 and client2 to list the shares:

root@client1:~> showmount -e myserver
Export list for myserver:
/data/media          client1,client2
/data/backup         client1,client2,client3

On client3 it will lead to an error:

root@client3:~> showmount -e myserver
rpc mount export: RPC: Authentication error; why = Failed (unspecified error)

The downside is that NFS v2 and v3 mounts will not work anymore, because a mount command in this versions needs to contact rpc.mountd.

Links

• NFS share hide directories and folders for users without permission
• Debian NFS Server Setup: NFSv4 only

On a TYPO3 v12 system one of our customers got this error when editing a mask content element:

No content edit permission for user 23 on page 42 1437679657

Exception code 1437679657 has the following comment in the source code:

A non page record is edited. If there is a parent page row, check content edit right of user

In my case it was a sys_file_reference entry that had a different pid than the tt_content element it was linked to. I have no idea how that happened; most likely a bug when copying or moving content elements in early stages of the project when things were in flux.

The backend user had access to the page with the content element, but not to the pid of the sys_file_reference record.

Solution

Find all affected content elements:

SELECT sfr.uid, sfr.pid as sfr_pid, tt_content.pid AS t_pid, tt_content.CType
  FROM sys_file_reference AS sfr
  JOIN tt_content ON tt_content.uid = sfr.uid_foreign
WHERE
  sfr.tablenames = "tt_content"
  AND sfr.pid != tt_content.pid
LIMIT 100

Now fix the file references:

UPDATE sys_file_reference
  INNER JOIN tt_content ON sys_file_reference.uid_foreign = tt_content.uid
SET
 sys_file_reference.pid = tt_content.pid,
 sys_file_reference.tstamp = UNIX_TIMESTAMP()
WHERE
 sys_file_reference.pid != tt_content.pid
 AND sys_file_reference.tablenames = "tt_content"

And in the end check if the records have the correct page IDs now:

SELECT
  sys_file_reference.uid AS sfr_uid,
  sys_file_reference.pid AS sfr_pid,
  tt_content.uid AS tt_uid,
  tt_content.pid AS tt_pid
FROM sys_file_reference, tt_content
WHERE
  tt_content.uid = sys_file_reference.uid_foreign
  AND sys_file_reference.tablenames = "tt_content"
  AND sys_file_reference.uid IN (94,95,96,97)