I agree with Mark's synopsis. It is likely that the "backup" of system tables is done as some other host user - e.g. "Fred" does a bcp out of the system tables - and "Fred" has a login account locally and the remote file system's host machine also recognizes the login "Fred" (or at least there is a matching uid). On the other hand, the "sybase" user that is running the backup is likely only known to the local host....and while the local presentation of the remote file system *suggests* that it is writable by the "sybase" user (e.g. someone likely just tried setting the permissions locally), the remote host has no knowledge of the "sybase" host uid. As a result, it is trying to write as either the "group" (gid of "dba") or "world"....both of which are read-only.
A quicker way to test this would be to log into the DB host as "sybase" user and try to "touch" a file in that file system - e.g.
(as sybase user on the DBMS host)
touch /net/134.163.248.45/sybase/sybbkup/CPDMDR/bkup/writetest.txt